On Tue, 14 Feb 2023 09:22:00 GMT, Richard Reingruber <rr...@openjdk.org> wrote:
>> The original assumption does not always hold anymore and should therefore >> relaxed. > > I think `unextended_sp < sp` is possible on x86 when interpreter entries > generated by `MethodHandles::generate_method_handle_interpreter_entry()` are > executed. They modify `sp` ([here for > example](https://github.com/openjdk/jdk/blob/7f71a1040d9c03f72d082e329ccaf2c4a3c060a6/src/hotspot/cpu/x86/methodHandles_x86.cpp#L310-L314)) > but not `sender_sp` (`InterpreterMacroAssembler ::_bcp_register`). >From `frame_x86.hpp`: // The interpreter and adapters will extend the frame of the caller. // Since oopMaps are based on the sp of the caller before extension // we need to know that value. However in order to compute the address // of the return address we need the real "raw" sp. By convention we // use sp() to mean "raw" sp and unextended_sp() to mean the caller's // original sp. by that definition `unextended_sp` is always > `sp`. If something has violated that definition/convention then we may have bigger problems! ------------- PR: https://git.openjdk.org/jdk/pull/12535
