On Tue, 3 Nov 2026 05:20:56 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:
>
> Rename to cont_popframe_reexecute_entry with its own CodeletMark, arm
> returns nullptr, review comment wording
src/hotspot/share/prims/jvmtiEnvBase.cpp line 2553:
> 2551: if (!is_interpreted[frame_count]) {
> 2552: javaVFrame* jvf = vfs.asJavaVFrame();
> 2553: if (vfs.reg_map()->in_cont()) {
Nit: This needs to be commented properly. What does check at line 2553 mean?
Does it mean the frame is frozen in a stack chunk?
Please, add a comment, so there is no need to dig for it.
src/hotspot/share/prims/jvmtiEnvBase.cpp line 2556:
> 2554: assert(_state->is_virtual(), "invariant");
> 2555: if (frame_count == 0) {
> 2556: // If the top frame is in the heap, PopFrame is not supported.
Nit: The comment at line 2556 is not fully correct. As is for compiled frames
only.
Should say: `If the top frame is compiled and in the heap...`
src/hotspot/share/prims/jvmtiEnvBase.cpp line 2595:
> 2593: } else {
> 2594: Deoptimization::deoptimize_frame(java_thread, frame_sp[i]);
> 2595: }
Nit: This also needs to be explained in the comment.
Why do we need two different ways of deoptimization?
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/32661#discussion_r4452229762
PR Review Comment: https://git.openjdk.org/jdk/pull/32661#discussion_r4452264567
PR Review Comment: https://git.openjdk.org/jdk/pull/32661#discussion_r4452236402
