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

[David Holmes]

On Thu, 31 Oct 2024 02:50:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

Of course you are racing with the execution of those other threads either way. In contrast if you do this at a safepoint you know the exact state of each thread and will know, for example, that the timer was created before the thread could terminate.

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

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