JEP 132: More-prompt finalization

[Rezaei, Mohammad A.]

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.

-          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.

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

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

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.

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/20150531/407bebf2/attachment.htm>