[concurrency-interest] Exception handling & Executors
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