OutOfMemoryError on OSF1

Discussion in 'Java' started by spam_to_dev_null@yahoo.com, Sep 14, 2005.

  1. Guest

    Learned Readers:

    The following program runs out of memory on my OSF1
    platform but seems to work OK on the NT, Solaris, and
    Linux hosts I've got access to. Does anyone have any
    ideas on what's going on and/or how to work around the
    problem? TIA,

    % uname -a
    OSF1 sys1 V5.1 1885 alpha

    % java -version
    java version "1.4.1"
    Java(TM) 2 Runtime Environment, Standard Edition
    Fast VM (build 1.4.1-2, native threads, mixed mode, 06/18/2003-17:51)

    % java Display
    0 free memory: 206817680
    1 free memory: 206565520
    2 free memory: 206318720
    3 free memory: 206071920
    4 free memory: 205808736
    5 free memory: 205561936
    6 free memory: 205315136
    7 free memory: 205068336
    ....
    2217 free memory: 2078272
    2218 free memory: 1831472
    2219 free memory: 1584672
    2220 free memory: 1337872
    2221 free memory: 1091072
    2222 free memory: 827888
    2223 free memory: 581088
    2224 free memory: 334288
    2225 free memory: 87488
    2226 free memory: 518520832
    2227 free memory: 518274032
    2228 free memory: 518010848
    2229 free memory: 517764048
    .... <lots more mem-grow sequences ommitted>
    4290 free memory: 2573488
    4291 free memory: 2326688
    4292 free memory: 2079728
    4293 free memory: 1816544
    4294 free memory: 1569744
    4295 free memory: 1322944
    4296 free memory: 1076144
    4297 free memory: 829344
    4298 free memory: 582544
    4299 free memory: 335744
    4300 free memory: 72560
    java.lang.OutOfMemoryError
    at java.awt.image.DataBufferInt.<init> DataBufferInt.java:41)
    at java.awt.image.Raster.createPackedRaster(Raster.java:452)
    at
    java.awt.image.DirectColorModel.createCompatibleWritableRaster(DirectColorModel.java:1015)
    at java.awt.image.BufferedImage.<init>(BufferedImage.java:259)
    at Display.<init>(Display.java:97)
    at Display.main(Display.java:113)

    Note: 200 * 300 = 60000 pixels required for each
    Image, and the free memory differences between
    displays tends to be 246800. It appears that for
    some reason the gc couldn't run when there was only
    72560 bytes available for the next Image. Any
    ideas why??

    Here's the contents of Display.java:

    import java.awt.*;
    import java.awt.image.*;
    import java.awt.geom.*;
    import javax.swing.*;

    class DisplayPanel extends JPanel
    {
    private Image curImage = null;

    public void setDisplayImage (Image newImage)
    {
    curImage = newImage;
    revalidate ();
    repaint ();
    }

    public void paintComponent (Graphics g)
    {
    if (curImage == null)
    return;

    Rectangle r = getBounds ();
    g.clearRect (0, 0, r.width, r.height);

    g.drawImage (curImage, 0, 0, null);

    curImage.flush (); // doesn't help on OSF1
    curImage = null; // doesn't help
    }
    }

    class Display extends JFrame
    {
    static long count = 0L;
    static Runtime runtime = Runtime.getRuntime ();

    Display () throws Exception // Exceptions from invokeAndWait
    {
    super ();

    final DisplayPanel displayPanel = new DisplayPanel ();
    displayPanel.setPreferredSize (new Dimension (200, 300));

    getContentPane ().add (displayPanel);
    setSize (200, 300);

    setVisible (true);

    final int rgb[] = new int[200 * 300];

    int alpha = 0xff000000;
    int red = 150, grn = 150, blu = 150;
    int redInc = 2, grnInc = 3, bluInc = 5;

    while (true)
    {
    int val = alpha + (red << 16) + (grn << 8) + blu;
    for (int i = 0; i < 200 * 300; i++)
    rgb = val;

    red += redInc;
    blu += bluInc;
    grn += grnInc;

    if (red > 250 || red < 50) redInc *= -1;
    if (grn > 250 || grn < 50) grnInc *= -1;
    if (blu > 250 || blu < 50) bluInc *= -1;

    final BufferedImage im = new
    BufferedImage (200, 300, BufferedImage.TYPE_INT_ARGB);
    im.setRGB (0, 0, 200, 300, rgb, 0, 200);

    SwingUtilities.invokeAndWait (new Thread ()
    {
    public void run ()
    {
    // setPriority (Thread.MIN_PRIORITY); // doesn't help
    System.out.println (count++ + " free memory: " +
    runtime.freeMemory ());
    displayPanel.setDisplayImage (im);
    // System.gc (); // doesn't help
    // yield (); // doesn't help
    }
    });
    }
    }

    public static void main (String args[]) throws Exception
    {
    new Display ();
    }
    }
    , Sep 14, 2005
    #1
    1. Advertising

  2. Roedy Green Guest

    On 13 Sep 2005 18:51:05 -0700, wrote or
    quoted :

    > It appears that for
    >some reason the gc couldn't run when there was only
    >72560 bytes available for the next Image. Any
    >ideas why??


    see http://mindprod.com/jgloss/packratting.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 14, 2005
    #2
    1. Advertising

  3. Guest

    Hmmmm.....so, you're saying to rearrange things as:

    Runnable runner = new Runnable ()
    {
    S.o.p. (...);
    displayPanel.setDisplayImage (im);
    };
    SwingUtilities.invokeAndWait (runner);
    runner = null;

    OK, I just ran it, and my long counter var made it all the way to
    Long.MAX_VALUE without tossing the cookies. :)

    YOU DA MAN! Thanks a million, or make that thanks a MAX_VALUE.
    , Sep 14, 2005
    #3
  4. wrote:
    >
    > The following program runs out of memory on my OSF1
    > platform but seems to work OK on the NT, Solaris, and
    > Linux hosts I've got access to. Does anyone have any
    > ideas on what's going on and/or how to work around the
    > problem? TIA,


    From another posting, you seem to have fixed your problems, but anyway...

    > Image, and the free memory differences between
    > displays tends to be 246800. It appears that for
    > some reason the gc couldn't run when there was only
    > 72560 bytes available for the next Image. Any
    > ideas why??


    You will get an OutOfMemoryError if the gc fails to free-up a certain
    proportion of the heap, even when there is enough memory for the
    allocation that caused it. Running the GC is very expensive. If it ran
    for every few allocations with low memory the performs would be somewhat
    underwhelming.

    > while (true)
    > {
    > [...]
    > final BufferedImage im = new
    > BufferedImage (200, 300, BufferedImage.TYPE_INT_ARGB);
    > im.setRGB (0, 0, 200, 300, rgb, 0, 200);
    >
    > SwingUtilities.invokeAndWait (new Thread () {


    No reason to create a Thread here, that you don't actually run. Runnable
    is sufficient.

    You are continually creating (but not flushing) images and queuing them
    up for display. You happen to be lucky enough that thread running this
    just happens to be running with priority one notch lower than the thread
    reading off the queue.

    > public void run ()
    > {
    > // setPriority (Thread.MIN_PRIORITY); // doesn't help


    Set the AWT Event Dispatch Thread (EDT) to min priority? No, I don't
    suppose that'll help. :) Also Thread.setPriority might not work for a
    started thread (well, it might not do anything anyway).

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, Sep 14, 2005
    #4
  5. Roedy Green Guest

    On Wed, 14 Sep 2005 09:23:51 +0100, Thomas Hawtin
    <> wrote or quoted :

    >No reason to create a Thread here, that you don't actually run. Runnable
    >is sufficient.

    Swing calls your Runnable.run but it does NOT create a new thread to
    do it. It is much more efficient than starting a new thread.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 14, 2005
    #5
  6. Guest

    OK, thank you to all who have replied. I thought
    I'd fixed the problem, but it seems to be trickier
    than I'd thought. The Thread that creates new
    BufferedImages send 'em to be displayed via:

    Image curImage = null;
    Runtime runtime = Runtime.getRuntime ();

    public void newImage (Image newImage)
    {
    curImage = newImage;
    repaint ();
    }

    public void paintComponent (Graphics g)
    {
    Rectangle r = g.getBounds ();
    System.out.println (runtime.freeMemory ());
    g.displayImage (curImage, 0, 0, r.width, r.height, Color.black,
    null);
    curImage.flush ();
    curImage = null;
    r = null;
    g = null;
    }

    When I run this on my OSF1 system, it displays
    a couple thousand images but then tosses an
    OOME in spite of printing out that there's tons of
    memory available. So, according to Roedy's above
    mentioned link, the GUI is running out of memory.

    What am I missing as far as freeing things up??
    I even tried putting in System.gc () calls, but to
    no avail. And, I tried putting in a monitor instead
    of null as the last arg to displayImage, but that
    didn't seem to work either.
    , Sep 15, 2005
    #6
  7. Roedy Green Guest

    On 13 Sep 2005 18:51:05 -0700, wrote or
    quoted :

    > int val = alpha + (red << 16) + (grn << 8) + blu;
    > for (int i = 0; i < 200 * 300; i++)
    > rgb = val;


    Of course, if all you were trying to do was to produce a display that
    changes shade frequently, you could just do that much more quickly
    with a fillRect in your paintComponent and dispense with the Image
    altogether. I assume though the real program does something more
    interesting with the Image.
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 18, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jussi Mononen

    Math::Pari test fail on Compaq OSF1 5.1b

    Jussi Mononen, Jan 2, 2004, in forum: Perl
    Replies:
    0
    Views:
    689
    Jussi Mononen
    Jan 2, 2004
  2. =?Utf-8?B?RGF2ZQ==?=

    Serialize session state & OutOfMemoryError?

    =?Utf-8?B?RGF2ZQ==?=, Sep 8, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    2,531
    =?Utf-8?B?RGF2ZQ==?=
    Sep 8, 2005
  3. Replies:
    7
    Views:
    418
    Roedy Green
    Sep 18, 2005
  4. Edmond Rusjan

    Python-2.3.4 on OSF1 V4.0?

    Edmond Rusjan, Nov 19, 2004, in forum: Python
    Replies:
    4
    Views:
    382
    Edmond Rusjan
    Nov 23, 2004
  5. Ivo Raisr

    Python-2.3.4 on OSF1 V4.0?

    Ivo Raisr, Aug 29, 2008, in forum: Python
    Replies:
    0
    Views:
    238
    Ivo Raisr
    Aug 29, 2008
Loading...

Share This Page