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