On 03/22/2016 10:28 PM, Kim Barrett wrote:
On Mar 22, 2016, at 5:24 AM, Per Liden <[email protected]> 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
