[concurrency-interest] Exception handling & Executors

Dawid Kurzyniec dawidk at mathcs.emory.edu
Wed Oct 26 00:24:55 EDT 2005

Joe Bowbeer wrote:

>On 10/25/05, Jan Nielsen <jnielsen at sungardsct.com> wrote:
>>With respect to your comment below about not being able to do anything
>>with an out-of-memory condition, could you not reliably release, for
>>example, cached data in an OutOfMemoryError handler:
>In my experience, recovery from OOME is dicey at best and therefore
>the only robust approach is to design and implement the app in such as
>way that OOME never happens.
>(Note: real-time Java tells a different story.)
>I haven't investigated carefully why OOME recovery is dicey, but since
>nothing is supposed to catch it I assume that once it is thrown the
>system is in an unrecoverable state: no cleanup has been performed
>along the way, connections and streams are broken, third-party
>libraries are left in some indeterminate state, etc.
I think that you have just said precisely why it is dicey (at least it 
convinced me): OOME can be thrown by any memory allocation attempt, 
including that performed by the library code that you don't control. If 
the allocation was attempted inside a synchronized block, the error 
causes the abrupt completion, and may leave shared data structures in an 
inconsistent state, since no library is actually written to guard 
against OOME. It is a bit similar to dangers of Thread.stop(), although 
just a little bit less bad, since OOME is not asynchronous.

>If your app could control where the OOME occurs then it would have a
>better chance to catch it and recover -- by releasing buffers, for
>example.  But I don't have a lot of faith that this can be done
>reliably (or efficiently).
If something can be safely released to recover from OOME, it is better 
to make that something soft -referenceable, in which case it will be 
automatically released, *preventing* OOME, when you're running low on 
memory. Soft-referenced objects are released only if the system cannot 
otherwise satisfy an allocation request.

The problem with OOME is that you never know which thread will 
experience it first if you are running low on memory.


More information about the Concurrency-interest mailing list