On Tue, 27 Oct 2026 18:55:01 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 the >> interpreter deopt entry after push_return_frame, the x86 deopt entry reloads >> rsp from last_sp for that, aarch64 already does. 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 breakp... > > Shiv Shah has updated the pull request incrementally with two additional > commits since the last revision: > > - Pass an int, a long and an Object through the popped frames and check them > after reexecution > - Require jvmti for the new PopFrames descriptors Added multi argument cases. testedMethod in popframes001a and the linkToStatic target in the invariant test now take an int, a long and an Object and check all three after the pop. One float word could not show a size or order mistake in the copy. The new descriptors also require jvmti ------------- PR Comment: https://git.openjdk.org/jdk/pull/32661#issuecomment-6450968421
