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

[Markus Grönlund]

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