Timer death

[David Holmes]

Pawel Veselov said the following on 07/15/10 10:08:
>> Florian Weimer said the following on 07/14/10 23:25:
>>> * Pawel Veselov:
>>>> The fact that I catch any Throwable around the code that threw the
>>>> OOM error didn't particularly help. The error was logged, but the
>>>> timer thread still died.
>>> By definition, a VM which throws an Error (or even
>>> VirtualMachineError) is unstable and needs to be restarted.  The
>>> description of VirtualMachineError makes that pretty clear.  You
>>> cannot even know that the thread that triggers such exceptions is
>>> responsible for their actual cause.
>> An OutOfMemoryError for the Java heap does not fall into that category. OOM
>> is a transient failure in many circumstances.
> 
> Not to be a nag here, but VirtualMachineError javadoc says "Thrown to
> indicate that the Java Virtual Machine is broken or has run out of
> resources necessary for it *to continue operating*.", and
> OutOfMemoryError extends VME. 

I think it is a historical mistake that OOME is a subclass of VME, as 
least so far as the non-recoverability in the Java-heap is concerned. I 
would suggest (somewhat tongue-in-cheek) that it was done at a time when 
people were far more familiar with OOM being a fatal error in C, than 
with it being a transient condition in a GC'd language. That said there 
should have been different OOME types for the Java heap and native-heap 
exhaustion (the latter of which is typically so fatal you don't even get 
the OOME thrown).

> It is true that it is a transient
> failure in many circumstances, but if its impossible to find out, for
> an application, what the circumstances and implications are, along
> with whether these errors are even being thrown around, what should
> the application do?

Serious applications that get OOME for heap exhaustion typically attempt:
- retry (GC could be in progress)
- request explicit GC
- request explicit finalization
- free up other memory used by the application (eg purge data structures)
- some combination of the above

Cheers,
David Holmes