Ian Rogers wrote: > Thanks Jeroen, it's clear now. The problem with a phantom reference is > that when we collect the thread local we should also really make > collectable all of the values set to thread locals. A phantom reference > won't do this and so introduces a memory leak until something can run > over the queue of phantom references freeing all the allocated thread > local slots. As you say, we can use phantom references, wouldn't > another way be to implement say our own system weak reference, with a > guarantee there are no references and weak references to the object? > Having a thread that polls a normally empty queue seems undesirable > both for this and Classpath bug 29499.
The thread doesn't actually need to poll (ReferenceQueue.remove() is a blocking operation), but burning a thread on this does suck. OTOH, there are a lot of other areas in the class lib that create background threads. I think the best thing would be to have a VM interface that handles the clean up and provide a default implementation that uses PhantomReference and allows VMs to provide a more efficient clean up mechanism. Ideally the mechanism would be flexible enough to also be used for #29499. OpenJDK has the sun.misc.Cleaner class for this. It extends PhantomReference, but it is treated specially by the finalizer thread, so that these aren't actually enqueued but processed by the finalizer thread itself. Regards, Jeroen
