Re: Out-of-Memory Handling in Long-Running / Server Applications

Randall R Schulz <[email protected]> Sun, 13 Apr 2008 16:58:34 -0700
Newsgroups gmane.comp.windows.devel.java.advanced
Message-ID <[email protected]>
On Sunday 13 April 2008 16:06, Endre Stølsvik wrote:
> Peter Booth wrote:
> > Here's my two cents:
> >
> > Catching an OutOfMemory error is a waste of time, because by the
> > tim eyou get that error all bets ar eoff an dthere is no guarantee
> > that the VM is functional.
>
> As mentioned, I've also heard this. I'd like to have pointers to
> actual documentation describing this, because I don't necessarily
> believe in it. See my other post in this thread about why I don't
> necessarily blindly believe that the OOM should come on any random
> thread. And I specifically don't understand why there shouldn't be
> any guarantee that the VM is functional after an OOM.

Depending on your code and its execution patterns, it _may_ be possible 
to meaningfully handle OOM errors, but I tend to doubt it.

But consider, you cannot control or predict (even using thread 
priorities) when one of the non-main threads executes. In particular, 
you cannot assume, ensure or guarantee that one of these background 
threads created by the JVM itself will not execute while your test 
allocation is in effect.

Keep in mind that while Java has thread synchronization primitives, it 
has no way to create JVM-wide critical section and lacking that, you 
cannot guarantee that some other thread won't encounter a failed 
allocation when your thread exhausts available heap space.

Multi-core and / or multi-processor systems only increase the likelihood 
that inopportune thread activations will occur.

As for recovery, the same lack of guarantees holds. It's not that the 
JVM per se becomes unstable after an OOM, but object allocation is so 
thoroughly ubiquitous in Java programs that any period during which RAM 
cannot be allocated is a time during which all threads are at risk.


> ...
>
> Endre.


Randall Schulz

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com