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

Coleen Phillimore coleenp at openjdk.org
Fri Jun 17 16:40:11 UTC 2022


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

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

it's not 'f'.

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

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


More information about the hotspot-runtime-dev mailing list