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

[Erik Österlund]

Hi Robbin,

Looks good.

Thanks,
/ERik

On 2018-04-12 22:27, Robbin Ehn wrote:
> 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