(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