JEP 132: More-prompt finalization

[Peter Levart]

Hi Moh,

On 06/01/2015 04:42 AM, Rezaei, Mohammad A. wrote:
>
> The problems start with the ReferenceQueue object and the heavy 
> synchronization in it. Consider structures like j.u.WeakHashMap that 
> need to expunge entries. If such structures are made somewhat 
> concurrent, the lock in ReferenceQueue starts to become a serious problem:
>
> -In structures that are concurrent at the entry level (like jdk 8’s 
> ConcurrentHashMap), if methods like get() or put() try to expunge, the 
> lock in ReferenceQueue renders the structures non-concurrent.
>

The presented prototype changes the implementation of ReferenceQueue. It 
doesn't use a lock any more for enqueu-ing when there are no waiters and 
never for poll-ing. ReferenceQueue.poll() is a single volatile read when 
queue is empty and a read followed by CAS when it is not (with retries 
when contended). If there is a desire and new API could be extended, the 
method like the following:

Iterator<Reference<? extends T>> pollChunk(int maxChunkSize);

...could return a chunk of enqueued references (or an empty iterator) so 
that the reduced number of CAS instructions per de-queued reference 
could be traded for the greater probability of retries because of 
contention.

> -In structures that are multi-reader-single-writer locked, read 
> methods cannot expunge (because they have to promote to a writer), but 
> they can’t even check the queue, because that turns the multi-reader 
> structure into a synchronized one.
>

By checking you mean poll() which also de-queues a reference if 
available? What do you do when this happens. Would you need a peek() 
method maybe?

> -In addition to expunge calls contending on the ReferenceQueue lock, 
> ReferenceHandler thread can also contend on the same lock.
>

That's right. And in the presented prototype, this is minimized by 
allowing ReferenceHandler thread to enqueue a chunk of pre-prepared 
references in one go, minimizing the need to frequently notify any 
possible waiters via a lock.notifyAll().

> -There is no fast clear() method on ReferenceQueue. That would be 
> quite useful on a resize event.
>

This would be easy to implement if new API could be added.

> The above issues forced us to have a dedicated thread that does 
> periodic expunging of References. This works ok under light load, but 
> can fall behind under heavy load.
>

Because of the overhead/bottleneck of the reference processing I assume. 
It would be great if you could check whether the prototype in webrev.02 
improves your situation. It should be simple. Just compile the sources 
and prepend the resulting classes to the bootclasspath of the JDK.

Regards, Peter

> Thanks
>
> Moh
>
> @Moh
>
> Can you elaborate some more on what twists were necessary or what 
> problems you had?
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20150601/611459e0/attachment.htm>