RFR: 8352251: Implement Cooperative JFR Sampling [v16]

[Markus Grönlund]

On Mon, 5 May 2025 20:19:51 GMT, Martin Doerr <mdoerr 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`)?

Yes, because StackWaterMarkSet unwind needs the "current frame"  as a starting point (for Interpreter frames, it's using fp instead of sp). That's why the ljf is still set "normally". But we add the _last_java_sender_fp specifically for the JFR sampler at this, and a two other sites. The JFR sampler selects the ljf over the CPU context. But In this case, because of StackWatermarkSet::after_unwind, we cannot use the _last_java_fp StackWatermarkSet is using. That would sample the frame that is about to pop. We need to sample the sender that we are returning to.

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

PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2852320337