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

[Robbin Ehn]

Thanks, Robbin!

On 04/12/2018 10:51 PM, Kim Barrett wrote:
>> On Apr 12, 2018, at 4:27 PM, Robbin Ehn <robbin.ehn at oracle.com> 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
> 
> Looks good.
>