JDK-8308043 : Deadlock in TestCSLocker.java due to blocking GC while allocating
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: 21
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2023-05-14
  • Updated: 2023-12-29
  • Resolved: 2023-05-17
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11 JDK 17 JDK 21
11.0.23-oracleFixed 17.0.11-oracleFixed 21 b23Fixed
Related Reports
Duplicate :  
Relates :  
Description
The following test timed out in the JDK21 CI:

gc/cslocker/TestCSLocker.java

Here's a snippet from the log file:

#section:main
----------messages:(8/332)----------
command: main -Xmx256m gc.cslocker.TestCSLocker
reason: User specified action: run main/native/othervm -Xmx256m gc.cslocker.TestCSLocker 
started: Sun May 14 00:09:45 UTC 2023
Mode: othervm [/othervm specified]
Timeout information:
--- Timeout information end.
finished: Sun May 14 00:21:43 UTC 2023
elapsed time (seconds): 718.384
----------configuration:(0/0)----------
----------System.out:(2/38)----------
sleeping...
Timeout refired 480 times
----------System.err:(0/0)----------
----------rerun:(39/7096)*----------

<snip>

result: Error. Program `/opt/mach5/mesos/work_dir/jib-master/install/jdk-21+23-1940/linux-x64.jdk/jdk-21/bin/java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 718378ms).

The test task's JVM args are:
-XX:+UseZGC -XX:+ZGenerational


Comments
[jdk11u-fix-request] Approval Request from Amos “Backporting for parity with jdk 11.0.23-oracle. No risk, test fix. UnClean backport. SAP nightlies passed on 2023-12-21”
22-12-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/2394 Date: 2023-12-15 06:47:57 +0000
15-12-2023

Fix request [17u] I backport this for parity with 17.0.11-oracle. No risk, only a test change. Resolved ProblemList, marked clean. Test passes. SAP nightly testing passed.
30-11-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/1997 Date: 2023-11-29 14:32:14 +0000
29-11-2023

As the JDK-8308589 excluded the test from GenerationalZGC runs, there is no sense now to verify this. Closing as is.
18-07-2023

Changeset: 285c833f Author: Erik Österlund <eosterlund@openjdk.org> Date: 2023-05-17 11:47:30 +0000 URL: https://git.openjdk.org/jdk/commit/285c833ffacdaabe7c4955cbbafb3bc459d26784
17-05-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13989 Date: 2023-05-15 14:26:42 +0000
15-05-2023

In this test, the following happens: Thread A: starts thread B Thread B: produces garbage provoking GCs randomly Thread A: starts thread C Thread C: locks GC locker in JNI, blockingly waits for thread A to signal it should be released Thread A: prints "sleeping", which inside of the printing implementation allocates memory, which needs a GC -------------------- deadlock --------------------- GC is waiting for thread C, thread C is waiting for thread A, thread A is waiting for GC. This was supposed to happen after, if that println allocation didn't get stuck on GC: Thread A: signals thread C to unlock GC locker This test could cause test failure with any concurrent GC. In fact it could cause test failures with all GCs, if you are unlucky enough that that allocation in the println statement ends up being the one triggering a GC.
15-05-2023

Somewhat similar to JDK-8293289 but does not need -Xcomp.
15-05-2023