Busting "java.lang.outofmemory"

Discussion in 'Java' started by Rajesh.Rapaka, Jul 13, 2005.

  1. Hi,
    I am working on a project in which when i run out of memory, I get a
    "Java.lang.outofmemory" exception. But I am not able to catch this !
    i.e is every function has a try catch statement. But I am not able to
    get hold of this exception.

    Well u might be wondering what i wud like to do after catching it....
    well I'd like to tell the user that his memory is over !!

    Am I not able to catch it? or doesnt java has a way to catch this
    exception?

    plz help,
    regards,
    Rajesh Rapaka.
     
    Rajesh.Rapaka, Jul 13, 2005
    #1
    1. Advertising

  2. Rajesh.Rapaka

    Daniel Dyer Guest

    On Wed, 13 Jul 2005 10:08:37 +0100, Rajesh.Rapaka
    <> wrote:

    > Hi,
    > I am working on a project in which when i run out of memory, I get a
    > "Java.lang.outofmemory" exception. But I am not able to catch this !
    > i.e is every function has a try catch statement. But I am not able to
    > get hold of this exception.
    >
    > Well u might be wondering what i wud like to do after catching it....
    > well I'd like to tell the user that his memory is over !!
    >
    > Am I not able to catch it? or doesnt java has a way to catch this
    > exception?


    You don't have to catch it for every method call, just for every thread on
    which it could occur since it will propagate up the call stack. If you
    are using Java 5 this is made easy by the new
    Thread.setUncaughtExceptionHandler method. If not, you would need to put
    a try...catch around the code in your main method and the code in the run
    methods of any threads you spawn.

    But you will have to be careful what you do when you catch it since you
    won't have much/any memory to work with, so it might not work reliably.

    Dan.

    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Jul 13, 2005
    #2
    1. Advertising

  3. On 13 Jul 2005 02:08:37 -0700, Rajesh.Rapaka wrote:

    > I am working on a project in which when i run out of memory, I get a
    > "Java.lang.outofmemory"


    No such error!

    >..exception. ...


    No you don't. What you are getting is an *error*,
    not an exception. Assuming you mean..
    <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/OutOfMemoryError.html>

    Please copy/paste errors, rather than typing 'something like'
    what it says. That wastes your time and our bandwidth.

    See below..

    >..But I am not able to catch this !
    > i.e is every function has a try catch statement. But I am not able to
    > get hold of this exception.
    >
    > Well u might be wondering what i wud like to do after catching it....
    > well I'd like to tell the user that his memory is over !!
    >
    > Am I not able to catch it?


    Sure you are..

    Are you catching Exceptions[1], ..or Errors[2]?

    (note that while both are Throwable[3],
    // do dangerous stuff
    ...
    } catch(Exception e) {

    ....will not catch classes under the Error hierarchy.)

    [1] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Exception.html>
    [2] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Error.html>
    [3] <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html>

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    == Proudly Made On Earth ==
     
    Andrew Thompson, Jul 13, 2005
    #3
  4. Rajesh.Rapaka

    Martin Jost Guest

    "Daniel Dyer" <> schrieb im Newsbeitrag news:eek:...
    > On Wed, 13 Jul 2005 10:08:37 +0100, Rajesh.Rapaka
    > <> wrote:
    >
    > > Well u might be wondering what i wud like to do after catching it....
    > > well I'd like to tell the user that his memory is over !!
    > >
    > > Am I not able to catch it? or doesnt java has a way to catch this
    > > exception?

    >
    > You don't have to catch it for every method call, just for every thread on
    > which it could occur since it will propagate up the call stack.


    I'm fighting myself with this problem right now.
    So here are my findings/observations: (In no particular order)
    1.
    You also need to be aware of your AWT/Swing threads.
    You need to catch the error in each of them (besides the threads you started explicitly)
    One point would be the ActionListener kicking off your action.

    2.
    (And probably most important) OutOfMemory is an "Error" not an Exception.
    So if you catch Exceptions, you simply will miss the Errors.
    So you have to catch the specific Error, all Errors or maybe even Throwable.
    (But then you get all of them...)

    3.
    If you have no memory left, it seems the handling may well trigger at once the next OutOfMemory.
    So you need a trick like that: (Borrowed from an older posting I found with google)

    private static byte[] emergencyMem = new byte[8192];
    public .... main(String[] a) {
    try {
    runApplication();
    } catch (OutOfMemoryError e) {
    emergencyMem = null;
    // ...Rest of handling
    }
    }

    HTH

    Martin
     
    Martin Jost, Jul 13, 2005
    #4
  5. Rajesh.Rapaka

    E.Otter Guest

    I'm of the opinion that something like an "OutOfMemoryError" and just about
    any other thing that ends with "Error" should not be caught. Its not
    really a bug or problem in your code its a problem with the environment the
    program is running in. Let the user see the problem. Your code needs to do
    something and the user has a PC with either not enough memory or just too
    much stuff currently running. Your code can't fix it. The user needs the
    smack upside the head to get a better system or shut some junk down.
     
    E.Otter, Jul 18, 2005
    #5
  6. On Mon, 18 Jul 2005 02:34:58 GMT, E.Otter wrote:

    > I'm of the opinion that something like an "OutOfMemoryError" and just about
    > any other thing that ends with "Error" should not be caught.


    As a general rule - that is idiotic.

    Window.setAlwaysOnTop() is a method introduced in 1.5.
    If you try it in a pre 1.5 VM you will get a 'NoSuchMethodError',
    but that is no reason to throw an error up before the end user.
    The programmer can simply start a thresad that keeps bringing the
    desired window to front. Not as neat and elegant as 'AlwaysOnTop',
    but still entirely workable.

    OOME's can be handled in a better manner by the programmer
    as well.

    >..Its not
    > really a bug or problem in your code its a problem with the environment the
    > program is running in.


    Like program designed to load up to 50 images is asked to
    load 327? Yes, it might be a problem with the environment,
    or how the user is using/abusing the program ..but simply
    dumping an error to stderr and exiting is most often neither
    necessary nor optimal.

    > Let the user see the problem.


    Tell 'em nothing, if you don't have to. It only confuses them.

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    You Can't Prove It Won't Happen
     
    Andrew Thompson, Jul 18, 2005
    #6
  7. Rajesh.Rapaka

    Guest

    E.Otter wrote:
    > I'm of the opinion that something like an "OutOfMemoryError" and just about
    > any other thing that ends with "Error" should not be caught. Its not
    > really a bug or problem in your code its a problem with the environment the
    > program is running in. Let the user see the problem. Your code needs to do
    > something and the user has a PC with either not enough memory or just too
    > much stuff currently running. Your code can't fix it. The user needs the
    > smack upside the head to get a better system or shut some junk down.


    FWIW, I'm not of that opinion.

    I recently wrote a GUI for an application: this application reads and
    analyses loads of files. If the user tries to analyse too large a
    system, then the application will run out of memory.

    The problem is that when this OutOfMemoryError is thrown by the
    application, if it's not caught, then the GUI will just hang. It won't
    report the Error automatically. Thus the user waits for a while,
    guesses something's gone horribly wrong, and rips it all down.

    It's much better to throw up a warning dialog, telling him that the
    universe is finished and he might as well give up.

    Yes, I know: you cannot guarantee that there will be enough memory to
    throw up the dialog, but I tried, nonetheless, and testing has shown
    that the system will throw up the dialog 60% of the time. Yes, for the
    other 40%, the user is just waiting for the bus that will never come;
    but 60% is better than nothing.

    Also, I've noticed that, even when there's no memory to throw up a
    dialog, the JVM can always (apparently) do a System.out.println(); so I
    do this, too. Unfortunately, most users will start the application by
    double-clicking a jar file, in which case the println() sends the
    message into deep space somewhere; but again: a little effort can *try*
    to allieviate the user's frustration.

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.
     
    , Jul 18, 2005
    #7
  8. On 18 Jul 2005 00:42:03 -0700, wrote:

    > Yes, I know: you cannot guarantee that there will be enough memory to
    > throw up the dialog, but I tried, nonetheless, and testing has shown
    > that the system will throw up the dialog 60% of the time. Yes, for the
    > other 40%, the user is just waiting for the bus that will never come;
    > but 60% is better than nothing.


    60% of the time?! When I was fighting memory leaks in some
    image software - I found I could get a dialog every time so
    long as I'd prepared and packed it first (ready - just in case).

    OTOH, I also like the idea mentioned by Martin (# 3).
    <http://groups-beta.google.com/group/comp.lang.java.programmer/msg/01e160bb68b85329>
    Instant emergency memory!

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    A By-Product Of The TV Industry
     
    Andrew Thompson, Jul 18, 2005
    #8
  9. Rajesh.Rapaka

    Guest

    Andrew Thompson wrote:
    > On 18 Jul 2005 00:42:03 -0700, wrote:
    >
    > > Yes, I know: you cannot guarantee that there will be enough memory to
    > > throw up the dialog, but I tried, nonetheless, and testing has shown
    > > that the system will throw up the dialog 60% of the time. Yes, for the
    > > other 40%, the user is just waiting for the bus that will never come;
    > > but 60% is better than nothing.

    >
    > 60% of the time?! When I was fighting memory leaks in some
    > image software - I found I could get a dialog every time so
    > long as I'd prepared and packed it first (ready - just in case).
    >
    > OTOH, I also like the idea mentioned by Martin (# 3).
    > <http://groups-beta.google.com/group/comp.lang.java.programmer/msg/01e160bb68b85329>
    > Instant emergency memory!
    >
    > --
    > Andrew Thompson
    > physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    > A By-Product Of The TV Industry


    Hi, Andrew,

    Thanks for the link; I've toyed with this technique (admittedly to no
    great extent) and couldn't quite get it to work. This thought was
    floating in my head that probably sabotaged my attempts: surely just
    setting the variable to null won't force the garbage collector to
    immedately free the memory before the next line is executed? Surely
    setting the variable to null just identifies it for collection
    *whenever* the garbage collector decides to get off his sofa and do
    some work?

    I will, however, put more effort into pre-manufacturing a JDialog,
    though; I had no idea that this sort of problem could be handled with
    100% satisfaction.

    Ta, chuck,

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.
     
    , Jul 19, 2005
    #9
  10. On 19 Jul 2005 00:58:34 -0700, wrote:

    > Andrew Thompson wrote:

    ...
    >> 60% of the time?! When I was fighting memory leaks in some
    >> image software - I found I could get a dialog every time so
    >> long as I'd prepared and packed it first (ready - just in case).

    ...
    > I will, however, put more effort into pre-manufacturing a JDialog,
    > though; I had no idea that this sort of problem could be handled with
    > 100% satisfaction.


    100% satisfation guaranteed - or your money back!

    But, more seriously.. If you ever see that fail, I
    would be interested in hearing about it.

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    Where No Fan Has Gone Before
     
    Andrew Thompson, Jul 19, 2005
    #10
  11. Rajesh.Rapaka

    Martin Jost Guest

    <> schrieb im Newsbeitrag news:...
    > Andrew Thompson wrote:
    > > 60% of the time?! When I was fighting memory leaks in some
    > > image software - I found I could get a dialog every time so
    > > long as I'd prepared and packed it first (ready - just in case).
    > >
    > > OTOH, I also like the idea mentioned by Martin (# 3).
    > > <http://groups-beta.google.com/group/comp.lang.java.programmer/msg/01e160bb68b85329>
    > > Instant emergency memory!


    Ok, just to get the credits right - I've borrowed the code from a posting of Stefan Matthias Aust in a German Java newsgroup.

    > Surely
    > setting the variable to null just identifies it for collection
    > *whenever* the garbage collector decides to get off his sofa and do
    > some work?


    This was also discussed in the German thread (http://groups-beta.google.com/group/de.comp.lang.java/browse_thread/thread/a9d918a222935b39)
    The gc should get off of its sofa really fast, because there is work to do. (In fact you just got an OOME)
    There was also discussed, that another thread might use the memory, before the current thread can use it.
    My own tests show, that you might need more memory, depending on what you plan to do.

    Martin
     
    Martin Jost, Jul 19, 2005
    #11
  12. On Tue, 19 Jul 2005 13:16:03 +0200, Martin Jost wrote:
    ....
    (reserving bytes in case of OOME)

    > My own tests show, that you might need more memory,
    > depending on what you plan to do.


    Thanks for the clarification and links, Martin.

    I have been meaning to try that technique.
    Maybe I'll get around to it someday..

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    Presented In DOUBLE VISION Where Drunk
     
    Andrew Thompson, Jul 19, 2005
    #12
  13. Hi all,
    Thanks for the replies. Seems like there is no way using which we can
    free memory manually. all we can do is NULL the variables and wait for
    the VM to perform the GC.

    Why are we forced to WAIT?? is there a bypass or secret passage to
    activate the Garbage Collector function from the JVM ??something like
    piercing into the JVM and activating the GC funtion.

    Well if there is no way that i can free my used memory immediately (
    like as in C++, i suppose) there is no point in using the java
    technology for softwares, specially where there is huge memory
    management requirement. because we already have delays from the
    program, then the delays from hardware, then the delays from OS and
    added to this, we have delays from JAVA itself ???

    Well my complaint is not just the delay. But this delay is provocating
    the crash of the system. Because when I use a mountain of memory, I
    force it to get GC'd. But since the gc doesnt want to do it *now* the
    mountain of NULL'ed variables is not ready to be used. and when
    immediately, with i need another mountain, this will give an
    OutOfMemoryError. But if the GC performs its job, I will not loose my
    job !! :)

    plz do tell me if there another way by which we can peep into the JVM
    and activate the GC funtion. or somehow perform the GC rather than
    praying for GOD!!!
    regards,
    Rajesh Rapaka.
     
    Rajesh.Rapaka, Jul 25, 2005
    #13
  14. On 25 Jul 2005 08:22:32 -0700, Rajesh.Rapaka wrote:

    > Thanks for the replies. Seems like there is no way using which we can
    > free memory manually. all we can do is NULL the variables and wait for
    > the VM to perform the GC.


    What happened when you did that?

    --
    Andrew Thompson
    physci.org 1point1c.org javasaver.com lensescapes.com athompson.info
    Presented in BC [Brain Control] Where Available
     
    Andrew Thompson, Jul 25, 2005
    #14
  15. Rajesh.Rapaka

    John Currier Guest

    > Thanks for the replies. Seems like there is no way using which we can
    > free memory manually. all we can do is NULL the variables and wait for
    > the VM to perform the GC.


    If you null the variables the GC will be able to do its job when you
    "need another mountain."

    John
    http://schemaspy.sourceforge.net

    p.s. it's null, not NULL. This isn't a macro-based language.
     
    John Currier, Jul 25, 2005
    #15
  16. Rajesh.Rapaka

    Martin Jost Guest

    "Rajesh.Rapaka" <> schrieb im Newsbeitrag news:...
    ....

    >Why are we forced to WAIT?? is there a bypass or secret passage to
    > activate the Garbage Collector function from the JVM ??something like
    > piercing into the JVM and activating the GC funtion.


    You could try to use System.gc():
    System.gc()
    ------------------
    public static void gc()Runs the garbage collector.
    Calling the gc method suggests that the Java Virtual Machine expend effort toward recycling unused objects in order to make the memory they currently occupy available for quick reuse. When control returns from the method call, the Java Virtual Machine has made a best effort to reclaim space from all discarded objects.

    The call System.gc() is effectively equivalent to the call:

    Runtime.getRuntime().gc()

    See Also:
    Runtime.gc()
    ------------------
    BUT... the thread I already quoted strongly suggested, that the gc works best, when left alone.

    HTH

    Martin
     
    Martin Jost, Jul 26, 2005
    #16
  17. Rajesh.Rapaka

    Guest

    Hi, Rajesh,

    You wrote, "Because when I use a mountain of memory, I
    force it to get GC'd."

    Remember, the garbage collector does just that: it collects garbage,
    i.e., memory that's reserved for use, but whose users no longer have
    interest in it. If you're using a mountain of memory, it may be that
    you just don't have enough RAM.

    If, for example, you've 1mb of RAM and need to loaded a 2mb jpeg into
    memory, then no amounf of garbage collection, and no other language's
    memory management algorithms, will help you.

    ..ed

    --
    www.EdmundKirwan.com - Home of The Fractal Class Composition.
     
    , Jul 26, 2005
    #17
  18. Rajesh.Rapaka

    Martin Jost Guest

    > If, for example, you've 1mb of RAM and need to loaded a 2mb jpeg into
    > memory, then no amounf of garbage collection, and no other language's
    > memory management algorithms, will help you.


    Two notes...

    1.
    You are aware, that the jre might/does _not_ use all memory on your machine by default ?
    E.g. my version (1.4.2_06-b3) has options for that:
    -Xms<size> set initial Java heap size
    -Xmx<size> set maximum Java heap size
    -Xss<size> set java thread stack size

    This comes with a note: "The -X options are non-standard and subject to change without notice."
    You might need to bump these to use the available memory.
    (Does someone know, how to get hold of the defaults for those ?)

    2.
    What version of the JRE are you using ?
    It seems that older versions had their share of problems concerning GC.

    HTH

    Martin
     
    Martin Jost, Jul 27, 2005
    #18
    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. Michael Borgwardt

    java.lang.OutOfMemory

    Michael Borgwardt, May 7, 2004, in forum: Java
    Replies:
    8
    Views:
    3,530
    Boudewijn Dijkstra
    May 15, 2004
  2. Rune
    Replies:
    2
    Views:
    557
    Kevin McMurtrie
    Feb 19, 2005
  3. Replies:
    25
    Views:
    9,519
  4. Vepxistqaosani

    Python busting out

    Vepxistqaosani, Nov 14, 2003, in forum: Python
    Replies:
    2
    Views:
    272
    Ben Finney
    Nov 14, 2003
  5. Ananth
    Replies:
    8
    Views:
    4,215
    Jason Cavett
    Mar 5, 2008
Loading...

Share This Page