RFR: 8278053: serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java failing in loom repo with Xcomp

[Coleen Phillimore]

On Fri, 17 Jun 2022 15:47:02 GMT, Ron Pressler <rpressler at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1970:
>> 
>>> 1968:   } else {
>>> 1969:     // caller might have been deoptimized during thaw but we've overwritten the return address when copying f
>>> 1970:     ContinuationHelper::Frame::patch_pc(caller, caller.raw_pc());
>> 
>> What is raw_pc() vs pc() ?  why? is _cont.is_empty() true here? ie. a bit more explanation would be useful here.
>
> raw_pc is the "physical" return pc, and could point to the deopt handler; pc is the original caller address whether or not the caller is deoptimized. So raw_pc and pc are different iff the frame is deoptimized.
> The relevant background is in the (pre-Loom) deoptimization-related frame methods, raw_pc and patch_pc (e.g. they say that deoptimizing stores the original pc in the frame).

Looking at JDK 18 runtime code for raw_pc() (should probably change the comment since it's not only used by deoptimization anymore): I'm told pc_return_offset is zero so the 'else' clause doesn't change the caller.pc if the frame isn't deoptimized.
Thanks to @pchilano also for explanation.
Can you change the comment to:
s/when copying f/\nwhen copying the caller frame from the heap. The caller.pc is unchanged otherwise./

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

PR: https://git.openjdk.org/jdk19/pull/12