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

[Johannes Bechberger]

On Sun, 1 Jun 2025 18:00:55 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> Yes, so I only start the thread walking if necessary
>
> I see. With a bounded queue as used in this solution, it can work quite nicely, that is, if the thread is actually on CPU in native, and just not waiting - if waiting (which is most likely) then pending requests could take a long time to be sent to consumers.
> 
> I also understand better the optimization you tried as part of async walk in native and frames. Also quite nice, to walk from the last JfrSampleRequest and do equals to "batch" the top JFR sample requests that are the same (i,.e taken for the ljf). Maybe you can retry that again, but then you need to save the sid AND the tid to be reused for the top equal requests (you only need stacktrace.record_inner() for one request). Its a nice optimization.

The problem is when in between queue processing a new JFR chunk is started. This caused problems before.

I would leave these kinds of optimizations for later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25302#discussion_r2120501728