David.Holmes at oracle.com
Thu Jul 15 01:45:10 UTC 2010
Martin Buchholz said the following on 07/15/10 11:37:
> On Wed, Jul 14, 2010 at 17:47, David Holmes <David.Holmes at oracle.com> 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
> 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.
More information about the core-libs-dev