-
Type:
Bug
-
Resolution: Unresolved
-
Priority:
P3
-
Affects Version/s: 27
-
Component/s: hotspot
While working on a another RFE [1], my changes in code [2] and timing triggered a potential bug [3], which turned to be completely unrelated to the code change I was working on.
The test test/jdk/java/lang/Thread/virtual/KlassInit.java is stuck under particular conditions.
The test basically starts a number of virtual threads, which compete for KlassInit.TestClass.<clinit> method.
The <clinit> method has a CountDownLatch, so the first virtual thread would block on the latch, while the rest of them would either be:
a. Preempted when the virtual thread is not pinned:
Interpreted code of KlassInit.lambda$testReleaseAtKlassInitInvokeStatic1$0 -> InterpreterRuntime::resolve_from_cache() -> ... LinkResolver::resolve_static_call(...init_mode=init_preemptable...) -> ... -> InstanceKlass::initialize_preemptable() -> ...
-> ObjectSynchronizer::waitUninterruptibly() -> ... -> ObjectMonitor.wait() -> Continuation::try_preempt() // successful
b. Waiting on class initialization lock being pinned to carrier thread
C1/C2 compiled code of KlassInit.lambda$testReleaseAtKlassInitInvokeStatic1$0 -> resolve_static_call_blob -> SharedRuntime::resolve_static_call_C() -> ... -> LinkResolver::resolve_static_call(...init_mode=init...) -> ... - InstanceKlass::initialize() -> ...
-> ObjectSynchronizer::waitUninterruptibly() -> ... -> ObjectMonitor.wait() -> Continuation::try_preempt() -> freeze_internal() returns freeze_pinned_cs error and code proceeds to PlatformEvent::park()
The test expects all threads mentioned above to be in WAITING state, which happens in case <a>. However when running the test with -Xcomp, I see that the test sometimes is stuck, because there are threads in RUNNABLE or PINNED state (case <b> above).
How to reproduce:
- Check out branch [2]
- Run test/jdk/java/lang/Thread/virtual/KlassInit.java
- Look for test cases with -Xcomp
For me the test times out on macosx-aarch64 intermittently, every 3-5 runs.
Not sure if this is a test or compiler vs. runtime bug, filing as compiler one.
[1] https://bugs.openjdk.org/browse/JDK-8313713
[2] https://github.com/kirill-shirokov/jdk/tree/8313713-add-comp-level-to-compilecommand
[3] https://github.com/kirill-shirokov/jdk/actions/runs/22463141520/job/65065273309
The test test/jdk/java/lang/Thread/virtual/KlassInit.java is stuck under particular conditions.
The test basically starts a number of virtual threads, which compete for KlassInit.TestClass.<clinit> method.
The <clinit> method has a CountDownLatch, so the first virtual thread would block on the latch, while the rest of them would either be:
a. Preempted when the virtual thread is not pinned:
Interpreted code of KlassInit.lambda$testReleaseAtKlassInitInvokeStatic1$0 -> InterpreterRuntime::resolve_from_cache() -> ... LinkResolver::resolve_static_call(...init_mode=init_preemptable...) -> ... -> InstanceKlass::initialize_preemptable() -> ...
-> ObjectSynchronizer::waitUninterruptibly() -> ... -> ObjectMonitor.wait() -> Continuation::try_preempt() // successful
b. Waiting on class initialization lock being pinned to carrier thread
C1/C2 compiled code of KlassInit.lambda$testReleaseAtKlassInitInvokeStatic1$0 -> resolve_static_call_blob -> SharedRuntime::resolve_static_call_C() -> ... -> LinkResolver::resolve_static_call(...init_mode=init...) -> ... - InstanceKlass::initialize() -> ...
-> ObjectSynchronizer::waitUninterruptibly() -> ... -> ObjectMonitor.wait() -> Continuation::try_preempt() -> freeze_internal() returns freeze_pinned_cs error and code proceeds to PlatformEvent::park()
The test expects all threads mentioned above to be in WAITING state, which happens in case <a>. However when running the test with -Xcomp, I see that the test sometimes is stuck, because there are threads in RUNNABLE or PINNED state (case <b> above).
How to reproduce:
- Check out branch [2]
- Run test/jdk/java/lang/Thread/virtual/KlassInit.java
- Look for test cases with -Xcomp
For me the test times out on macosx-aarch64 intermittently, every 3-5 runs.
Not sure if this is a test or compiler vs. runtime bug, filing as compiler one.
[1] https://bugs.openjdk.org/browse/JDK-8313713
[2] https://github.com/kirill-shirokov/jdk/tree/8313713-add-comp-level-to-compilecommand
[3] https://github.com/kirill-shirokov/jdk/actions/runs/22463141520/job/65065273309