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.hpp line 103: > 101: volatile CPUTimeLockState _cpu_time_jfr_locked = UNLOCKED; > 102: volatile bool _has_cpu_time_jfr_requests = false; > 103: JfrCPUTimeTraceQueue _cpu_time_jfr_queue{0}; Please initialize these fields in the initializer list, like the other fields. Also, what capacity will the JfrCPUTimeTraceQueue have with an initializer like the above - {0}? In GDB i see that the capacity is 10000. Each element is 48 bytes, meaning each thread now has an associated queue of 468 kb, almost 0.5 Mb. Is that correct? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2105860988
