Hi Martin,
Martin Buchholz said the following on 07/15/10 11:37:
On Wed, Jul 14, 2010 at 17:47, David Holmes <[email protected]> wrote:
Pawel Veselov said the following on 07/15/10 10:08:
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).
I agree that OOME in Java is more recoverable than similar occurrence in C,
and I have tried hard to write code that will not corrupt data structures
even in the presence of OOME, but it's hard to get such code right,
and most code out there doesn't even really try, so there is a good chance
that your application will no longer operate quite right. Really good
applications
will have redundancy at the process or machine (or datacenter!) level,
and on OOME, will die gracefully to be replaced by another instance.
You are of course completely right. OOMEs are only potentially
recoverable at the attempted allocation site. Once the OOME has
propagated you need all the intervening code to be async-exception safe
which is very rarely the case.
I stand corrected.
David Holmes
