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.
