On Wed, 15 Feb 2023 05:17:31 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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! I get the following values for `sp` and `unextended_sp` when running this test case: int sp = 0x7f9f1ec614e0, unextended sp = 0x7f9f1ec614e0 int sp = 0x7f9f1ec61538, unextended sp = 0x7f9f1ec61548 int sp = 0x7f9f1ec615a0, unextended sp = 0x7f9f1ec61598 // the assumption fails here int sp = 0x7f9f1ec61600, unextended sp = 0x7f9f1ec61608 int sp = 0x7f9f1ec61670, unextended sp = 0x7f9f1ec61688 ... ------------- PR: https://git.openjdk.org/jdk/pull/12535
