Analysis on JDK-8022321 java/lang/ref/OOMEInReferenceHandler.java fails intermittently
kim.barrett at oracle.com
Tue Mar 22 21:28:25 UTC 2016
> 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).
More information about the core-libs-dev