> On Mar 22, 2016, at 5:24 AM, Per Liden <per.li...@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).
