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

Robbin Ehn robbin.ehn at oracle.com
Wed Apr 11 13:17:46 UTC 2018

Thanks for reviews, here is an updated version:

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

(if you missed v2 it's here: http://cr.openjdk.java.net/~rehn/8195099/v2/)

Full: http://cr.openjdk.java.net/~rehn/8195099/v3/webrev/

Thanks, Robbin

On 04/10/2018 02:18 PM, 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