On Thu, 8 Oct 2026 19:54:49 GMT, Shiv Shah <[email protected]> wrote: > @sspitsyn @plummercj, Patricio took a look and had two points > > The caller could be compiled too. Never happens in this test, but my thaw > block only handles an interpreted caller and asserts otherwise. Also the > deopt in UpdateForPopTopFrameClosure::doit goes by frame id and only walks > the native stack, so a compiled caller still sitting in a chunk would never > be found. set_frame_pop deals with that case via fr.deoptimize(nullptr, > chunk). > > So, two options. > > Return JVMTI_ERROR_OPAQUE_FRAME from doit when the caller frame is in a > chunk. Then the thaw and x86 changes go away and the test just accepts that > error for virtual threads. That's Patricio's preference, this never worked > for vthreads and he doubts debuggers rely on it much. Spec allows it, though > the one vthread case it mentions for PopFrame is suspended at an event, which > is what we have here. > > Or keep the pop working and do it properly, compiled frozen caller deopted > the set_frame_pop way in doit, plus thaw handling it.
Talked to Patricio, going with the middle one, OPAQUE_FRAME from doit when the frozen caller is compiled, the thaw path stays for an interpreted caller. The deopt in doit for that case would never have found the frame anyway ------------- PR Comment: https://git.openjdk.org/jdk/pull/32661#issuecomment-6068567926
