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

[Robbin Ehn]

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