RFR: 8342818: Implement CPU Time Profiling for JFR

[Jaroslav Bachorik]

On Wed, 30 Oct 2024 07:36:01 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 788:
>> 
>>> 786: 
>>> 787:   // create timers for all existing threads
>>> 788:   MutexLocker tlock(Threads_lock);
>> 
>> When exactly is this called? The direct use of the Threads_lock raises concerns. Should this not be done at a global safepoint?
>
> This is called transitively from the Java code whenever the event is first enabled. So this should lead to a safepoint?

AFAIK, we are removing the timers once all recordings with the cpu profiler event are closed. And would re-add them when another recording is started later, right?
In that case, if we force a global safepoint in order to init/remove timers we could get an unexpectly high amount of safepoints, dependent on the external factors starting/stopping/configuring JFR recordings.

@dholmes-ora What exactly is the concern here? I just want to understand if the concern really warrants increasing the number of global safepoints when using JFR with this sampler.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20752#discussion_r1822167799