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