On Sun, 1 Jun 2025 07:26:19 GMT, Johannes Bechberger <jbechber...@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
