RFR: 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock [v3]
Axel Boldt-Christmas
aboldtch at openjdk.org
Wed Dec 3 18:37:44 UTC 2025
> The main threads call to `csLocker.unlock();` may cause an allocation which may trigger a GC. This can lead to a deadlock because we have a native thread which is waiting on a signal from the main thread (which is sent in `csLocker.unlock()`) to `ReleasePrimitiveArrayCritical`. Without the call to ReleasePrimitiveArrayCritical the some GCs may be blocked.
>
> I suggest we remove the dependency on a java thread for the `GetPrimitiveArrayCritical` / `ReleasePrimitiveArrayCritical` pair. And simply do the lock and the sleep inside native.
>
> * Testing
> * Stress testing test/hotspot/jtreg/gc/cslocker/TestCSLocker.java with both SerialGC and ZGC and small heap sizes
> * GHA
Axel Boldt-Christmas 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 six additional commits since the last revision:
- Remove problem-listing
- Merge remote-tracking branch 'upstream_jdk/master' into JDK-8373025
- Need to support windows as well
- Remove unused variable
- Fix the comment
- 8373025: Test: test/hotspot/jtreg/gc/cslocker/TestCSLocker.java may deadlock
-------------
Changes:
- all: https://git.openjdk.org/jdk/pull/28638/files
- new: https://git.openjdk.org/jdk/pull/28638/files/62d34e96..672b746e
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=28638&range=02
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=28638&range=01-02
Stats: 1699 lines in 51 files changed: 1321 ins; 166 del; 212 mod
Patch: https://git.openjdk.org/jdk/pull/28638.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/28638/head:pull/28638
PR: https://git.openjdk.org/jdk/pull/28638
More information about the hotspot-gc-dev
mailing list