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

Reply via email to