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

Andrei Pangin apangin at openjdk.org
Wed Jun 4 11:28:54 UTC 2025


On Wed, 4 Jun 2025 11:18:52 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 with a new target base due to a merge or a rebase. The pull request now contains 127 commits:
> 
>  - Merge branch 'master' into parttimenerd_cooperative_cpu_time_sampler
>  - Add error message on signal handler install failure
>  - Fix signal handler synchronization
>  - Improve
>  - Rename autoadapt
>  - Make process_cpu_time_request private and move up
>  - Reorder condition
>  - Tiny refactoring
>  - Restrict threads for which timers are created
>  - Fix tiny mistake
>  - ... and 117 more: https://git.openjdk.org/jdk/compare/7838321b...4fd4b673

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

> 609:   // increment the count of active signal handlers
> 610:   u4 old_value = Atomic::fetch_then_add(&_active_signal_handlers, (u4)1, memory_order_acq_rel);
> 611:   if ((old_value & STOP_SIGNAL_BIT) != 0) {

Combining stop signal with a counter is nice, you can then use `Atomic::cmpxchg` to avoid incrementing counter when the stop bit is set.

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

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


More information about the serviceability-dev mailing list