RFR: 8342818: Implement CPU Time Profiling for JFR [v4]

[David Holmes]

On Wed, 30 Oct 2024 09:05:42 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> 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.

@jbachorik if you take out the `Threads_lock` you will delay real safepoints. Direct use of the Threads_lock is not desirable as it can lead to unexpected deadlocks and interferes with safepoints.

If all you want is to create timers for all existing threads then use of a ThreadsListIterator should suffice as a snapshot.

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

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