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

[Ron Pressler]

On Fri, 17 Jun 2022 15:41:24 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Please review the following fix.
>> 
>> When JVM TI puts a thread's state in `interp_only_mode`, thaw takes the slow path and deoptimizes frames as they're thawed in `recurse_thaw_compiled_frame`. However, thawing a deoptimized frame's callee will override the frame's patched pc (to the deopt handler), essentially reverting the deoptimization. This fix patches the deoptimized return address after thawing the callee.
>> 
>> Passes loom tiers 1-5
>
> 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).

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

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