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

[Markus Grönlund]

On Fri, 23 May 2025 21:20:39 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:
> 
>   Fix compilation

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168:

> 166:   assert(jt != nullptr, "invariant");
> 167: 
> 168:   biased = false;

Can be moved after the has_last_Java_frame() check.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362:

> 360: #ifdef LINUX
> 361:   if (tl->has_cpu_time_jfr_requests()) {
> 362:     JfrTicks now = JfrTicks::now();

You should be able to reuse the already taken now, no?

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375:

> 373:     }
> 374:     queue.clear();
> 375:     tl->release_cpu_time_jfr_queue_lock();

Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106235901
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236251
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236738