RFR: 8343177: JFR: Remove critical section for thread id assignment

Markus Grönlund mgronlun at openjdk.org
Tue Oct 29 10:33:46 UTC 2024


Greetings,

With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments.

However, a critical section at this location makes it difficult to build robust signal handlers, for example, because we need help reading the thread ID.

We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude).

The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. 

Testing: jdk_jfr Tier 1- 3, Stress testing

Thanks
Markus

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

Commit messages:
 - 8343177

Changes: https://git.openjdk.org/jdk/pull/21756/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343177
  Stats: 79 lines in 10 files changed: 46 ins; 13 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21756.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21756/head:pull/21756

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


More information about the hotspot-dev mailing list