RFR: 8352251: Implement JEP 518: JFR Cooperative Sampling [v23]
Markus Grönlund
mgronlun at openjdk.org
Thu May 15 22:26:56 UTC 2025
On Thu, 15 May 2025 22:06:31 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:
>> Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision:
>>
>> growable array constructur without default initialization
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 687:
>
>> 685: Label slow_path;
>> 686: Label fast_path;
>> 687: safepoint_poll(slow_path, this_fp, true /* at_return */, false /* acquire */, false /* in_nmethod */);
>
> The way you moved the polling until after unwinding worries me a little bit.
>
> First of all, you have to change the InterpreterRuntime::safepoint_poll and InterpreterRuntime::at_unwind functions that call StackWatermarkSet::before_unwind to call after_unwind instead, to better reflect what is happening now. That's doable and should be straight forward so that's good.
>
> What I'm more worried about though, is what the JVMTI implications are. When single stepping in the debugger, it would seem that we now stop after unwinding instead of before. That seems like a change in debugger behaviour? I worry that previously you could see locals in the debugger before exiting while now you can't. I also have dark memories of seeing method exit JVMTI event assembly code that crops the expression stack assuming it belongs to the frame we are just returning from because that's how it worked. With fun code trying to deal with the oop maps being wrong across the event. Have you run any JVMTI method exit event tests?
The intent is to maintain the logical (Java and JVM) view that we have not popped the frame yet, which is why we still save the ljf to the original frame, just as before. Anything working with ljf, such as InterpreterRuntime::at_unwind(), should function as before.
All tiers 1-6 pass, but I can double check all the JVMTI tests specifically, as they are as you say, tricky.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2092040614
More information about the hotspot-jfr-dev
mailing list