RFR: 8373106: JFR suspend/resume deadlock on macOS in pthreads library

Markus Grönlund mgronlun at openjdk.org
Mon Jan 12 21:38:18 UTC 2026


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)

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

Commit messages:
 - 8373106

Changes: https://git.openjdk.org/jdk/pull/29178/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29178&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373106
  Stats: 62 lines in 1 file changed: 12 ins; 18 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/29178.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29178/head:pull/29178

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


More information about the hotspot-jfr-dev mailing list