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

[Markus Grönlund]

On Sun, 1 Jun 2025 07:26:19 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 two additional commits since the last revision:
> 
>  - Refactoring
>  - Remove convoluted native trace logic

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

> 40: #include "runtime/javaThread.hpp"
> 41: #include "runtime/osThread.hpp"
> 42: #include "runtime/safepointMechanism.hpp"

Not needed, since you have the .inline.hpp

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

> 100: 
> 101: u4 JfrCPUTimeTraceQueue::size() const {
> 102:   return Atomic::load(&_head);

Is this read from multiple threads? In that case, load_acquire().

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

> 198:   void sample_thread(JfrSampleRequest& request, void* ucontext, JavaThread* jt, JfrThreadLocal* tl);
> 199: 
> 200:   // sample all threads that are in native state (and requested to be sampled)

We are not really "sampling", but processing their queues, no?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119128911
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129239
PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2119129708