(Preliminary) RFC 7038914: VM could throw uncaught OOME in ReferenceHandler thread
Peter Levart
peter.levart at gmail.com
Mon May 6 21:44:06 UTC 2013
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.
>>
>>
>
More information about the core-libs-dev
mailing list