Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently

[Peter Levart]

On 03/22/2016 10:28 PM, Kim Barrett wrote:
>> On Mar 22, 2016, at 5:24 AM, Per Liden <per.liden at oracle.com> wrote:
>> One thing I like about this approach is that it's only the ReferenceHandler thread that pops of elements from the pending list and enqueues them. That simplifies things a lot.
> I like that too.  And hopefully we really can get rid of sun.misc.Cleaner (under whatever name).
>
>>  From a GC perspective I would however like to get away from the shared pending list and the pending list lock entirety and instead provide a VM downcall to get the pending list. The goal would of course be to have a more robust way of transferring the pending list to Java land, instead of today's secret handshake which is easy to get wrong. Also, not requiring the pending list lock (which is a Java monitor) to be held during a GC would also simplify things a lot on the GC side. E.g. the ReferencePendingListLockerThread could be removed completely.
> I’ve been thinking along the same lines.  I think having the pending list (and associated locking and notification) in Java is just making life difficult for ourselves, and that things could be much simpler if that whole protocol was owned by the VM.
>
> Once the reference handler thread has obtained the latest list, if it then wants to publish that list for other Java threads to help process, that’s a policy choice that can be explored on the Java side, with no impact on the VM (including the GC).
>

If the only blocking/waiting of ReferenceHandler thread was performed by 
native code, could it simply ignore Java thread interrupts? If this is 
possible, then the problems of InterruptedException allocation and 
consequent OutOfMemoryError(s) just disappear.

Regards, Peter