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

Robbin Ehn robbin.ehn at oracle.com
Thu Apr 12 20:27:28 UTC 2018

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

More information about the hotspot-dev mailing list