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

[David Holmes]

Catching ThreadDeath is futile. If someone is invoking stop() then you 
can encounter the ThreadDeath anywhere and it is impossible to write 
completely robust code in the face of such an async exception. So please 
let's not even go there. stop() is long deprecated and should never be used.

Backing up I think the try/catch(IE|OOME) around wait() is the most 
reasonable solution here. Anyone messing with instrumentation or 
overriding etc can break things - so be it - don't do that. 
StackOverflowError can also completely break many things - again it is 
effectively an async exception and writing async-exception-safe Java 
code is impractical if not impossible.

Cheers,
David

On 7/05/2013 7:44 AM, Peter Levart wrote:
>
> On 05/06/2013 09:42 PM, Peter Levart wrote:
>>
>> On 05/06/2013 05:03 PM, Alan Bateman wrote:
>>> On 06/05/2013 09:02, Thomas Schatzl wrote:
>>>> :
>>>>
>>>> Alan also mentioned something about instrumentation that can add memory
>>>> allocations basically anywhere.
>>>> As the reference handler code is plain java code, it will be
>>>> affected as
>>>> other java code.
>>> I mentioned instrumentation on the off-chance that there was more to
>>> this puzzle.
>>>
>>> I think Peter is right and the allocation of the InterruptedException
>>> seems to be the only place where OOME is possible in this code. Do
>>> you know if these tests call Thread.interrupt on random threads
>>> (maybe as a stress test)? It is possible to get a reference to the
>>> Reference Handler thread via Thread.getAllStackTraces and a few other
>>> APIs so maybe this what is going on. If the tests aren't calling
>>> interrupt on random threads then it suggests to me that there is
>>> something else going on, maybe there is a lurking VM bug.
>>>
>>> In any case, it seems safe to catch/ignore OOME here. One of the
>>> mails mentioned ThreadDeath and I don't know if want to expand the
>>> scope of the patch. That seems a case where it should be like the
>>> Cleaner and terminate the VM.
>>
>> I mentioned ThreadDeath as another possibility, similar to
>> InterruptedException, that could cause OOME. OOME that would result
>> from unsuccessful allocation of ThreadDeath error object in victim
>> thread should not be ignored though. But it seems that JVM designers
>> have already taken care of that, because contrary to
>> InterruptedException the ThreadDeath error object is allocated in
>> thread executing Thread.stop() method and this instance is later
>> raised as exception in victim thread. So OOME in Object.wait() can
>> only be caused by unsuccessful allocation of InterruptedException and
>> nothing else. That was my final conclusion. ThreadDeath thrown in
>> ReferenceHandler thread should not be caught and ignored.
>
> If anyone is stop()-ing ReferenceHandler thread then it should be
> stopped. Speaking of that, if ThreadDeath is thrown in the middle of
> Cleaner's thunk.run() processing, then the Cleaner will exit JVM. I
> think ThreadDeath should be separately caught and re-thrown instead.
>
> Regards, Peter
>
>>
>> Regards, Peter
>>
>>>
>>> -Alan.
>>>
>>>
>>
>