RFR: 8315827: Kitchensink.java and RenaissanceStressTest.java time out with jvmti module errors

Markus Grönlund mgronlun at openjdk.org
Tue Dec 5 19:13:44 UTC 2023


Greetings,

A deadlock interaction pattern has surfaced where the JFR sampler thread has suspended a thread, reportedly in state thread_in_java. That thread is currently running barrier code and is holding a semaphore as part of logging inside of LogFileOutput::write( ).

When the JFR thread sampler attempts to read the thread status from the thread object, it triggers the same barrier code, eventually waiting for the semaphore inside LogFileOutput::write( ). Since the owner is suspended, a deadlock ensues.

To avoid triggering barriers as part of the sampler code, we can avoid reading the thread status from the thread object as part of sampling. This is especially so because we know what the thread state is at this point, especially for _thread_in_java but also for _thread_in_native. It is most likely JavaThreadStatus::RUNNABLE (5). Write it as a constant.

Testing: jdk_jfr

Thanks
Markus

-------------

Commit messages:
 - 8315827

Changes: https://git.openjdk.org/jdk/pull/16982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16982&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315827
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16982/head:pull/16982

PR: https://git.openjdk.org/jdk/pull/16982


More information about the hotspot-jfr-dev mailing list