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/support/jfrThreadLocal.cpp line 548: > 546: #ifdef LINUX > 547: > 548: bool JfrThreadLocal::acquire_cpu_time_jfr_enqueue_lock() { Can you describe the lock protocol and why a thread must lock its thread-local queue? Is it because sampling interrupts can interleave after you have started to process a sample as part of a previous interrupt? src/hotspot/share/jfr/support/jfrThreadLocal.hpp line 373: > 371: #ifdef LINUX > 372: void set_cpu_timer(timer_t timer) { > 373: _has_cpu_timer = true; Does not necessarily have to be defined in the .hpp file. Please move to .cpp. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156788 PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2106156997
