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

[Erik Österlund]

Hi Robbin,

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

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

Otherwise it looks good to me. I note that the lack of 
release_store_fence() in critical_section_end() 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.

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