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

[Robbin Ehn]

Thanks, Robbin!

On 04/13/2018 11:02 AM, Erik Österlund wrote:
> 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
>