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 hotspot-dev
mailing list