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

[Martin Doerr]

On Tue, 13 May 2025 20:18:14 GMT, Markus Grönlund <mgronlun at openjdk.org> wrote:

>>> I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.
>> 
>> Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain: https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
>> Maybe we can find a way to discard samples after the return safepoint check?
>
>> > I think your version is not nicely implementable on platforms which don't have an FP register, but I'll take a look and think about it.
>> 
>> Update: I was thinking about emulating `make_sender_fp_current` by modifying the Back Chain: `std(sender_fp, _abi0(callers_sp), R1_SP);`. This would also hide the top frame from the sampler such that it doesn't sample the top frame after the return safepoint check. However, this would break concurrent thread stack processing (used by ZGC and ShenandoahGC) which relies on the Back Chain:
>> 
>> https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104
>> 
>> Maybe we can find a way to discard samples after the return safepoint check?
> 
> Why would it break stack watermark processing for only this platform? Stack watermark processing relies on the ljf, not the CPU context. That's why we (still) set the ljf to the frame to be popped, and provide the sender java fp as a separate field.

@mgronlun: I don't think I can get the top frame hiding trick to work on PPC64.
What we need to do is to hide the top interpreter frame from the sampler after the return safepoint check, right?
If I hide it from the sampler, I will also hide it from the concurrent thread stack processing code. And that causes errors.
I think the top frame hiding trick only works on platforms which use an FP register. Platforms like PPC64 and s390 don't have that.
Can we use a different mechanism to prevent the sampler from taking snapshots between the return safepoint check and the frame pop?
E.g., we could set a field in the JavaThread before the safepoint check and clear it after the frame pop. The sampler would have to discard samples when the JavaThread's field is set.

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

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