RFR (M) 8195099: Concurrent safe-memory-reclamation mechanism (original) (raw)

Robbin Ehn robbin.ehn at oracle.com
Tue Apr 10 14:42:38 UTC 2018

Hi Erik,

On 04/10/2018 02:45 PM, Erik Österlund wrote:

Hi Robbin,

The local counter loaded in criticalsectionbegin/end should not be volatile (the compiler will produce unnecessarily crappy code).

Thanks, fixed!

globalCounter.hpp lacks a few includes: memory/allocation.hpp and memory/padded.hpp.

Thanks, fixed!

Otherwise it looks good to me. I note that the lack of releasestorefence() in criticalsectionend() means that stores and loads can float up into the critical section. I'm assuming that is fine in the envisioned use cases, as long as accesses do not float out from the critical section.

Yes, you are correct, added a comment.

Full: http://cr.openjdk.java.net/~rehn/8195099/v2/webrev/ Inc : http://cr.openjdk.java.net/~rehn/8195099/v2/inc/webrev/

Thanks, Robbin

Thanks, /Erik On 2018-04-10 14:18, Robbin Ehn wrote: Hi all,

We have moved the global-counter to a separate change-set. The global-counter uses a counter to determine current generation. Any reader needs to have a local counter for which generation is currently read. By increment the global-counter and scan for threads reading an old generation and wait for them to complete, we know when an old generation is not visible (no pre-existing reader). In RCU terms, this creates a grace-period. Making this mechanism suitable for a read-mostly scenario. In this initial change-set we scan JavaThreads and the VMThread. A couple of enhancement to the global-counter will be looked into: - Quiescent state RCU semantic by using the natural state of JavaThreads in the VM. - Asynchronous write synchronize, where reclamation, if there are per-existing reader, is done by the last reader leaving that generation. - Register/deregister threads. The current usage is the upcoming hash-table which uses the global-counter to reclaim memory and to concurrently grow. We have also potential use-cases in other work-in-progress code. The new gtest passes on our platforms. For now you can look at the gtest if you think you have a use-case for this as an example. Code: http://cr.openjdk.java.net/~rehn/8195099/v1/webrev/ Issue: https://bugs.openjdk.java.net/browse/JDK-8195099 Thanks, Robbin

More information about the hotspot-dev mailing list