On Thu, 2 Jul 2026 06:36:58 GMT, Alan Bateman <[email protected]> wrote:
>> Though I will say that it seems very inconsistent that two very similar >> operations - terminate the current frame- would have different constraints >> in this regard. > > ForceEarlyReturn is simpler in that it just needs to arm the suspended target > VM to return early when resumed. > > PopFrame is more complicated as it involves removing the current activation > and restoring state to that the method can be re-invoked. Surprisingly, the > spec doesn't prohibit PopFrame when the target thread is suspended in a class > initializer. It fails with OPAQUE_FRAME of course because the caller is the > VM. Maybe some other VM might allow it but it's seems an insane thing to do > in the first place (the developer using a debugger wants to re-run the class > initializer??). Maybe some future work in this area could have the spec > prohibit it. The only difference I see between them is that force returns so we proceed after the call, and pop returns such that we redo the call. Both terminate the current activation immediately. I thought PopFrame implicitly prohibited class initializers because both frames must be Java frames? Though I suppose it is an implementation detail that class initializers have a bunch of native frames before them. Anyway more work needed on this aspect of the spec going forward. ------------- PR Review Comment: https://git.openjdk.org/valhalla/pull/2604#discussion_r3511227559
