(Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread

[Vitaly Davidovich]

Personally, I think I'd exit the VM in this case.  The odds of hitting OOM
while allocating TIE and having it be just a very unfortunate transient
condition are quite low; most likely, the VM is going to have lots of
trouble elsewhere anyway.

Also, by swallowing the OOM there and continuing makes an assumption that
the lock is still in valid/working state; that may be the case today, but I
don't know if that's a safe assumption generally.

Sent from my phone
On May 3, 2013 3:26 PM, "Peter Levart" <peter.levart at gmail.com> wrote:

>
> On 05/03/2013 07:47 PM, Thomas Schatzl wrote:
>
>> Hi,
>>
>>> Hi Tomas,
>>>
>>> I don't know if this is the case here, but what if the
>>> ReferenceHandler thread is interrupted while wait()-ing and the
>>> construction of InterruptedException triggers OOME?
>>>
>> I am sure this is the case - previously I thought InterruptedException
>> is a preallocated exception like others.
>> ObjectMonitor::wait() may throw it, by creating new InterruptedException
>> instances.
>>
>> Thanks!
>>
>> Now that we've found the very likely cause, what to do about it?
>>
>
> Maybe just ignore it since if it happens during wait(), the cause is
> supposed to be interrupted thread and the InterruptedException that was to
> be thrown would be ignored too:
>
>                         try {
>                             lock.wait();
>                         } catch (InterruptedException | OutOfMemoryError
> x) { }
>
> Regards, Peter
>
>  The current state of silently crashing the reference handler thread is
>> unsatisfying imo as it leads to very hard to find problems.
>>
>> The options I see all involve catching this (or any other OOME caused by
>> other means like the test program) and either recovering as much as
>> possible or exiting the VM (like in the sun.misc.Cleaner handling).
>>
>> Any other suggestions?
>>
>> Thanks,
>> Thomas
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130503/4e9a49c4/attachment.htm>