RFR: 8373106: JFR suspend/resume deadlock on macOS in pthreads library [v2]
Erik Gahlin
egahlin at openjdk.org
Tue Jan 13 13:21:54 UTC 2026
On Tue, 13 Jan 2026 12:05:41 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
>> Greetings,
>>
>> this change effectively reverts [JDK-8358429](https://bugs.openjdk.org/browse/JDK-8358429), which was an attempt to minimize the time the Threads_lock is held during JFR sampling. That change was premised on the, at the time, two known reasons for why we held the Threads_lock during the entire sampling interval.
>>
>> After this change, subtle deadlocks happened on macOS, very intermittently, in the pthreads library, in that a suspended thread could be the owner of an internal process lock, a process lock that was then needed when sending pthread_kill signal to resume it.
>>
>> By rolling back to holding the Threads_lock for the entire duration of the sampling interval (like we have done for many many years in the era before JFR Cooperative Sampling), we prevent JavaThreads from calling os::create_thread().
>>
>> I have decided to rollback the solution to the version we know work, instead of attempting a more granular solution, perhaps using sigprocmask() to create a critical section around pthread_create in os_bsd.cpp. This is something we might want to do later, but more time is then needed for falsifying / verifying the correct fix.
>>
>> Testing: jdk_jfr, stress testing
>>
>> Thanks
>> Markus
>>
>> PS Indirect barriers removed are explicitly re-inserted as per [JDK-8373485](https://bugs.openjdk.org/browse/JDK-8373485)
>
> Markus Grönlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>
> - remove extraneous assertion
> - Merge branch 'master' into 8373106
> - 8373106
Marked as reviewed by egahlin (Reviewer).
-------------
PR Review: https://git.openjdk.org/jdk/pull/29178#pullrequestreview-3655758172
More information about the hotspot-jfr-dev
mailing list