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

[Kim Barrett]

> 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.