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

[Markus Grönlund]

On Tue, 3 Jun 2025 12:39:47 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This is the code for the [JEP 509: CPU Time based profiling for JFR](https://openjdk.org/jeps/509).
>> 
>> Currently tested using [this test suite](https://github.com/parttimenerd/basic-profiler-tests). This runs profiles the [Renaissance](https://renaissance.dev/) benchmark with
>> - ... different heap sizes
>> - ... different GCs
>> - ... different samplers (the standard JFR and the new CPU Time Sampler and both)
>> - ... different JFR recording durations
>> - ... different chunk-sizes
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restrict threads for which timers are created

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 327:

> 325:     JfrThreadLocal* tl = jt->jfr_thread_local();
> 326:     if (tl->wants_async_processing_of_cpu_time_jfr_requests()) {
> 327:       if (!jt->has_last_Java_frame() || jt->thread_state() != _thread_in_native || !tl->try_acquire_cpu_time_jfr_dequeue_lock()) {

I recommend this order for higher probability:

1. jt->thread_state() != _thread_in_native
2. !tl->try_acquire_cpu_time_jfr_dequeue_lock()
3. !jt->has_last_Java_frame()

You need to restructure of course, to get the unlocking correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2123711980