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:

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

This code uses the Back Chain on PPC64 which will miss one frame if we have modified the Back Chain:
https://github.com/openjdk/jdk/blob/e7ce661adb01fba4bb690d51cc2858c822008654/src/hotspot/share/runtime/stackWatermark.inline.hpp#L104 

I've tried it and here's the extract from the hs_err file:
`assert(is_frame_safe(f)) failed: Frame must be safe`


V  [libjvm.so+0x1c9f670]  StackWatermark::assert_is_frame_safe(frame const&)+0xd0  (stackWatermark.cpp:180)
V  [libjvm.so+0x1ca3650]  StackWatermark::before_unwind()+0x1f0  (stackWatermark.inline.hpp:83)
V  [libjvm.so+0x1ca2b58]  StackWatermarkSet::before_unwind(JavaThread*)+0x58  (stackWatermarkSet.cpp:87)
V  [libjvm.so+0x1017210]  InterpreterRuntime::at_unwind(JavaThread*)+0x90  (interpreterRuntime.cpp:1182)
j  jdk.internal.classfile.impl.Util.writeList(Ljdk/internal/classfile/impl/BufWriterImpl;[Ljdk/internal/classfile/impl/Util$Writable;I)V+16 java.base at 25-internal


The difference on other platforms may be that they have several ways of finding the next frame. By FP register and by some kind of link. PPC64 only uses one way which is the Back Chain.

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

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