RFR: 8352251: Implement Cooperative JFR Sampling [v16]
Martin Doerr
mdoerr at openjdk.org
Mon May 5 20:22:49 UTC 2025
On Mon, 5 May 2025 19:56:43 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:
> > Isn't this problem already solved by using the `_last_sender_Java_fp`? Why do we need both, the frame pop before the safepoint check and the _last_sender_Java_fp trick?
>
> Because the sampler fetches the CPU context for threads running in state "_thread_in_Java". Without it, you can sample after the safepoint poll test is issued, but before the frame is popped. That sampled frame will represent something now being removed, and if the sender issues another call, also overwritten.
>
> It may help to think about how the JIT methods works - they pop their frames before issuing the method return safepoint poll test.
Ok. This makes sense. Thanks for the explanation!
Just trying to understand: What if we have the frame pop before the safepoint check like in JIT compiled code. Do we still need the `_last_sender_Java_fp` trick in this case (assuming we handle it like in the JIT compiled case and use `StackWatermarkSet::after_unwind` in `InterpreterRuntime::at_unwind`)?
-------------
PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2852238016
More information about the hotspot-jfr-dev
mailing list