RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]

[Markus Grönlund]

On Fri, 16 May 2025 22:11:07 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>> So there are two things here. My original comment was about the fact that enterSpecial always sets rbp so we shouldn’t need this special handling. The value fetched from the current rbp should give the same result, even for the return_barrier case (for which we currently do no special handling already). 
>> 
>> Then the other question is what kind of request will be created if we are in this case (rbp pointing to ContinuationEntry) and making sure it will be processed correctly later. If we are sampling after changing rbp to the ContinuationEntry in remove_activation, when building the request I see the pc will check for an interpreted frame and that `is_valid_interpreter_frame()` will also check. Then when processing the request, if this was a return_barrier case and we are still in the vthread context, in `compute_sender_frame()` we will eventually return the sender frame of enterSpecial and invalidate the request. Then we just proceed to record the stacktrace starting from this frame. So unless I missed something seems we need an extra check for this.
>
> That is very good spotted indeed. There is a race here if the top frame is invalidated and we just go with the sender (it would describe the carrier frames for the vthread, something I had some problems with in the very beginning).
> 
> My neurons about Continuations and "rbp in continuations" are unfortunately way off in DRAM, on some remote  NUMA node to boot.
> 
> Can you help me think out how to handle the Continuation specific things in parsing here?

> > Where do you suggest to place it best?
> 
> Should be in `FreezeBase::unwind_frames()`. That's where we change the anchor to the ContinuationEntry.

Fixed. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093730190