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

[Robbin Ehn]

Hi Erik,

On 04/10/2018 02:45 PM, Erik Österlund wrote:
> Hi Robbin,
> 
> The local counter loaded in critical_section_begin/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 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.

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
>