On Wed, 4 Jun 2025 14:24:04 GMT, Johannes Bechberger <jbechber...@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
