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