RFR: 8342818: Implement JEP 509: JFR CPU-Time Profiling [v50]

Markus Grönlund mgronlun at openjdk.org
Wed Jun 4 17:09:08 UTC 2025


On Wed, 4 Jun 2025 14:24:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 330:
>> 
>>> 328: void JfrCPUSamplerThread::stackwalk_threads_in_native() {
>>> 329:   ResourceMark rm;
>>> 330:   MutexLocker tlock(Threads_lock);
>> 
>> What exactly are we guarding against by holding the `Threads_lock`? Seems `ThreadsListHandle` should be enough.
>
> You're right.

The Threads_lock is required to prevent JFR from sampling through an ongoing safepoint, touching oops, which is not supported by most GCs as well as JFR evolving its global epoch (happens during safepoint) while both threads are outside the safepoint protocol. Can be optimized (later), see for example: https://github.com/openjdk/jdk/pull/25602

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2127062451


More information about the serviceability-dev mailing list