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

[Robbin Ehn]

Hi all, please review this change to the gtest.

I found an issue in the gtest, it have a theoretical worse case of several 
hundreds of seconds. With the jtreg timeout of 120 s this can cause sporadic 
failures and/or consume time. This is because the readers spent a big majority 
of the time inside the read-section, thus there is always a reader thread to 
wait for. When running the test on e.g. 1 CPU the write_synchronize will yield 
the CPU to a reader (or spin until sleep) but the each reader will consume it's 
timeslice. One generation can take one time-slice per reader thread and the test 
does at minimum one time 100000 write_synchronize.

I have limited the test to max 100000 write_synchronize or 1 seconds test time. 
On a normal machine the test now takes ~400ms (including ~50ms setup time).

Tested locally with 1, 2, many CPU's and I did a couple of hundreds of gtest 
runs on different platforms in mach5 and tier-1 run which include the gtests.

Inc: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/inc/webrev/
Full: http://rehn-ws.se.oracle.com/cr_mirror/8195099/v4/webrev/

Thanks, Robbin


On 2018-04-11 15:17, Robbin Ehn wrote:
> 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