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 ------------- Commit messages: - gclocker Changes: https://git.openjdk.org/jdk/pull/23367/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23367&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8192647 Stats: 936 lines in 37 files changed: 36 ins; 804 del; 96 mod Patch: https://git.openjdk.org/jdk/pull/23367.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23367/head:pull/23367 PR: https://git.openjdk.org/jdk/pull/23367
