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

[Patricio Chilano Mateo]

On Fri, 16 May 2025 09:05:19 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>>> Thanks. So if we create the request as mentioned before I’m not sure that check will do it. I see it’s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
>> 
>> Can you provide me with a technical snippet describing whtat you intend here? Thanks.
>
>> Thanks. So if we create the request as mentioned before I’m not sure that check will do it. I see it’s checking for enterSpecial instead of its caller. Also I see we only get there in the interpreted case, but the caller of enterSpecial could be compiled. I was thinking of an early check where if we are in a vthread and the sample request is not within the continuation just do a bias sampling.
> 
> Its only the interpreter that needs special handling for this case, because of the rbp thingy. The JIT should just work as normal. Thats why I stop iff the sampled interpreter frame is enterSpecial and is a termination point for the virtual thread.

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 here.

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

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