On Sun, 1 Jun 2025 18:00:55 GMT, Markus Grönlund <mgron...@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
