On Wed, 5 Feb 2025 14:38:45 GMT, Albert Mingkun Yang <ay...@openjdk.org> wrote:
>> Here is an attempt to simplify GCLocker implementation for Serial and >> Parallel. >> >> GCLocker prevents GC when Java threads are in a critical region (i.e., >> calling JNI critical APIs). JDK-7129164 introduces an optimization that >> updates a shared variable (used to track the number of threads in the >> critical region) only if there is a pending GC request. However, this also >> means that after reaching a GC safepoint, we may discover that GCLocker is >> active, preventing a GC cycle from being invoked. The inability to perform >> GC at a safepoint adds complexity -- for example, a caller must retry >> allocation if the request fails due to GC being inhibited by GCLocker. >> >> The proposed patch uses a readers-writer lock to ensure that all Java >> threads exit the critical region before reaching a GC safepoint. This >> guarantees that once inside the safepoint, we can successfully invoke a GC >> cycle. The approach takes inspiration from `ZJNICritical`, but some >> regressions were observed in j2dbench (on Windows) and the micro-benchmark >> in [JDK-8232575](https://bugs.openjdk.org/browse/JDK-8232575). Therefore, >> instead of relying on atomic operations on a global variable when entering >> or leaving the critical region, this PR uses an existing thread-local >> variable with a store-load barrier for synchronization. >> >> Performance is neutral for all benchmarks tested: DaCapo, SPECjbb2005, >> SPECjbb2015, SPECjvm2008, j2dbench, and CacheStress. >> >> Test: tier1-8 > > Albert Mingkun Yang has updated the pull request with a new target base due > to a merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Merge branch 'master' into gclocker > - review > - Merge branch 'master' into gclocker > - gclocker > Further it would be interesting to see how many retries there are in the > allocation loop with these jnilock* stress test. I added `QueuedAllocationWarningCount=1` to `test/hotspot/jtreg/vmTestbase/nsk/stress/jni/gclocker/gcl001.java` and saw retry never exceeds 10 for Serial/Parallel. > Which means that it might retry for a long time That occurs only when another java thread successfully triggers a gc, advancing the gc-counter, i.e. there is some system-wide progress. Per-thread progress is hard to guarantee, IMO. ------------- PR Review: https://git.openjdk.org/jdk/pull/23367#pullrequestreview-2595944041
