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

Per Liden per.liden at oracle.com
Wed Mar 23 09:05:06 UTC 2016


Hi,

On 2016-03-23 08:13, Peter Levart wrote:
>
>
> 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.

Yes, blocking in the VM here would ignore thread interrupts and not 
throw InterruptedException.

cheers,
Per



More information about the core-libs-dev mailing list