On Thu, 5 Nov 2026 15:40:54 GMT, Shiv Shah <[email protected]> wrote: >> When a virtual thread suspended at a breakpoint gets unmounted and mounted >> again only the top frame is thawed. The caller stays frozen in the stack >> chunk and the popped frame returns into the continuation return barrier. The >> interpreter's popframe entry treats that return address like a deoptimized >> caller, preserves the arguments, sets the reexecution bit and returns. The >> barrier then thawed the caller as a plain return. Arguments and bit left >> behind, no reexecution of the invoke, run() went on with a zero result. >> >> Thaw finishes it now. An interpreted caller gets the preserved arguments >> back on its expression stack and its return slot is patched to a new >> popframe reexecution entry of the interpreter, the mdp is set back to the >> invoke as well. A compiled caller frozen in the chunk is deoptimized from >> UpdateForPopTopFrameClosure::doit the same way set_frame_pop does it. Thaw >> leaves the arguments alone in that case and unpack_on_stack puts them back. >> A frozen compiled frame being popped stays opaque. >> >> A linkTo caller needs one more thing. The linker consumed the trailing >> MemberName before the target ran and the preserved arguments are sized by >> the target, so the MemberName is not among them. Thaw takes it from the >> caller's local 0 the way the interpreter's popframe entry does, the lookup >> from member_name_arg_or_null moved into a plain helper both can call. The >> arguments go one slot up and the MemberName goes back on top. >> >> popframes002 runs popframes001 on a virtual thread with the join Chris >> Plummer wrote enabled by a property in the debuggee. It unmounts the tested >> thread before the breakpoint so the caller is frozen when popped, and run() >> is excluded from compilation so this stays the interpreted case. >> popframes003 is the compiled caller case, -Xcomp with the breakpoint in a >> separate stop() so testedMethod keeps its compiled frame and run() stays >> frozen, the debugger pops frame 1 and the debuggee checks with WhiteBox that >> run() and testedMethod are compiled and that testedMethod ran twice. >> -XX:+PreserveFramePointer keeps the thaw on the slow path. Both fail on >> master without the hotspot change. popframes001 itself runs the plain case >> as before and is off the virtual problem list. If separate copies of the >> debugger and debuggee are preferred over the properties that is easy to >> change. PopFrameMethodNameInvariantTest got an unmount mode, the same >> linkToStatic pop on a virtual thread that sleeps before the breakpoint so its caller is frozen. >> >>... > > Shiv Shah has updated the pull request incrementally with one additional > commit since the last revision: > > Reword two comments in popframes001a
Looks good to me, thanks for all the updates. Just make sure ppc and s390 are fixed (or leave this enhancement unsupported on those platforms for now and keep tests problem-listed for them). ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/32661#pullrequestreview-5788229464
