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

Erik Gahlin egahlin at openjdk.org
Wed Dec 6 16:55:40 UTC 2023


On Tue, 5 Dec 2023 19:07:25 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

> 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

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16982#pullrequestreview-1768114723


More information about the hotspot-jfr-dev mailing list