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