On Fri, 23 May 2025 21:20:39 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 one > additional commit since the last revision: > > Fix compilation src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 168: > 166: assert(jt != nullptr, "invariant"); > 167: > 168: biased = false; Can be moved after the has_last_Java_frame() check. src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 362: > 360: #ifdef LINUX > 361: if (tl->has_cpu_time_jfr_requests()) { > 362: JfrTicks now = JfrTicks::now(); You should be able to reuse the already taken now, no? src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 375: > 373: } > 374: queue.clear(); > 375: tl->release_cpu_time_jfr_queue_lock(); Is this releasing a different lock from the one acquired? "dequeue" lock vs "queue" lock? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106235901 PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236251 PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106236738
