RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
Markus Grönlund
mgronlun at openjdk.org
Fri May 16 22:17:56 UTC 2025
On Fri, 16 May 2025 20:13:20 GMT, Patricio Chilano Mateo <pchilanomate 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.
>>
>> 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 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?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2093729472
More information about the hotspot-jfr-dev
mailing list