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

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


On Wed, 4 Jun 2025 07:00:51 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:
> 
>   Improve

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

> 236:   tl->cpu_time_jfr_queue().resize_for_period(_current_sampling_period_ns / 1000000);
> 237:   timer_t timerid;
> 238:   if (create_timer_for_thread(thread, timerid)) {

Timer creation failure is not an impossible situation, we should somehow let user know that not all threads are being profiled but without flooding in logs. One warning per profiling session may be a good compromise.
You can verify failure condition by setting low `ulimit -i`.

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

> 490:   assert(_sampler != nullptr, "invariant");
> 491:   if (info->si_signo != SIGPROF) {
> 492:     // not the signal we are interested in

No, I meant checking `si_code`. `si_signo` will always be the right one.
And this check should come first, before any assertions.

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

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


More information about the serviceability-dev mailing list