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

Peter Levart peter.levart at gmail.com
Mon May 6 19:42:38 UTC 2013


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.

Regards, Peter

>
> -Alan.
>
>




More information about the core-libs-dev mailing list