On Sat, 25 Oct 2025 02:40:03 GMT, Dean Long <[email protected]> wrote:
>> Just to add more context, not clearing last_sp will make this assert [1] >> fire if we freeze again. That assert is mostly a verification check, because >> we know the interpreter doesn’t set last_sp for the top frame when calling >> into the VM. But I don’t see a fundamental reason why it must be cleared >> (removing the assert and not clearing last_sp works). I don’t see any other >> code that checks last_sp needs to be cleared for the top frame (other than >> in the interpreter before calling into the VM). >> How about changing that last sentence with: `We also clear last_sp to match >> the behavior when calling the VM from the interpreter (we check for this in >> FreezeBase::prepare_freeze_interpreted_top_frame).` >> >> [1] >> https://github.com/openjdk/jdk/blob/87092ef1d97e00ddb6674b0e309f2f904d307604/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L136 > > FWIW, interpreter_frame_tos_address() behaves differently depending on if > last_sp() is cleared or not. I know deoptimization sets last_sp temporarily > but makes sure to clear it before giving control back to the interpreter. Right, but if `interpreter_frame_last_sp()` is the same as `sp()` then `interpreter_frame_tos_address()` will return the same value. My guess is that since we are already setting `_last_Java_sp` when making VM calls, there is no point in the extra bookkeeping of setting and clearing `interpreter_frame_last_sp` so we leave it as nullptr. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27802#discussion_r2466872228
