Re: FAQ, 4.1 OutOfMemoryException

[Chris Gray]

On Friday 14 January 2005 13:24, Andrew Haley wrote:
> Chris Burdess writes:
>  > Andrew Haley wrote:
>  > > Indeed.  The problem is that anything you do when catching an
>  > > OutOfMemoryException risks running out of memory!  There's not much
>  > > any java program can do other than logging the failure and exiting.
>  >
>  > To be pedantic, it's OutOfMemoryError,
>
> Ahh, cut 'n paste.
>
>  > and the same applies largely to any other Error (except possibly in
>  > the case of reflection tools).
>
> Not really.  For example, it's not unreasonable to catch
> java.lang.NoClassDefFoundError, which may be thrown when a subsystem
> is badly configured.

J2ME CLDC VMs are not required to handle Errors via the exception handling 
mechanism, which kind of implies that other VMs should try to do so.

An application _could_ handle an OOME by switching to a less memory-intensive 
algorithm or flushing caches, but I doubt that many do. It's a bit like doing 
something other than exit() when malloc returns NULL; a good idea in a 
compiler, but probably more trouble than it's worth in a run-off-the-mill 
app.

My own experience is that the feasibility of cleanly throwing OOME depends 
strongly on the complexity of the application. If you have 101 threads all 
trying to load classes and stuff then you'll probably end up with an OOME 
storm and end up crashing in the VM: with a single-threaded application 
you'll probably be able to throw the OOME, catch it in the 
uncaughtExceptionHandler of the root ThreadGroup, and do a clean exit.

-- 
Chris Gray                      /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi        http://www.kiffer.be/k/
address@hidden                         +32 3 216 0369

Visit us at Embedded World 2005 <http://www.embedded-world.de/>
22--24 Feb. 2005 at the Nürnberg Messe (Germany), booth 10-504