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

[Markus Grönlund]

On Fri, 16 May 2025 15:52:25 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>> "this_fp" means "this frame's fp", before it moved.
>
>> The JVMTI things should have already been done before we start to manipulate the rbp, just like before.
> 
> What I'm worried about is that the new order crashes the JVM when using method exit events and force early return.
> 
> What we used to do:
> 1. You are at a random bytecode that may or may not have an oop in top-of-stack. For the sake of example, let's assume TOS is an int for this particular bytecode.
> 
> 2. Force early return is invoked, saying "return with this oop". The expression stack is nuked, and the oop is placed top-of-stack. But the oop map for the current BCI says there should not be an oop there, so subsequent safepoint polls (I'm looking at you) are going to destroy the oop.
> 
> 3. "The only safepoint poll" on the way out of the frame, is the super special method exit JVMTI event. It knows that it's doing something dangerous by safepointing after the early return value is installed. In JvmtiExport::post_method_exit we read the oop before it's destroyed, call out to the JVMTI callback that can safepoint and destroy the oop, and before proceeding it writes the retained and nice oop to the top-of-stack, hence manually avoiding the oop map mismatch.
> 
> Since you moved the safepoint poll to after the method exit event handling, it feels like safepointing is going to destroy the top-of-stack oop again, because we assume the oop maps for the BCI we are at are sane, but they are not because of JVMTI.

Hmm. That is a complicated case indeed. Thanks for explaining it in detail.

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

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