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

[Peter Levart]

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.
>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20130506/546ba749/attachment.htm>