RFR: 8302745: sp > unextended_sp for interpreted to interpreted calls going through method handle linker

[Andrew Haley]

On Mon, 16 Feb 2026 13:39:37 GMT, Anton Artemov <aartemov at openjdk.org> wrote:

> Hi, please consider the following changes:
> 
> This a fix for `sp > unextended_sp` state, which can happen when interpreted -> interpreted calls go through a method handle linker method.
> 
> On x86 the issue is addressed by incrementing `r13` register value when the `memberName `appendix arg is being popped out. Additionally, some changes in JVMTI - related method `_remove_activation_preserving_args_entry` have to be done to reflect the changes.
> 
> On aarch64 the issue is addressed by keeping a 16-bytes aligned snapshot of the expression stack pointer (eps) in `r19` instead of the regular stack pointer, and an increment of that register value when the `MemberName `appendix arg is being popped out. Although due to the 16-bytes alignment the result of this increment is wiped out immediately, I think it is good to be consistent with x86 and have instructions in place.
> 
> Tested in tiers 1 - 7.

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 353:

> 351:   // set sender sp
> 352:   mov(r19_sender_sp, esp);
> 353:   andr(r19_sender_sp, r19_sender_sp, -16);

Suggestion:

  andr(r19_sender_sp, esp, -16);

src/hotspot/cpu/aarch64/methodHandles_aarch64.cpp line 302:

> 300:     __ pop(rmember);             // extract last argument
> 301:     __ mov(r19_sender_sp, esp);  // esp has been moved by 8 bytes, reflect it. The value in r19 will become frame's unextened_sp later on.
> 302:     __ andr(r19_sender_sp, r19_sender_sp, -16); // Force 16-bytes alignment. It wipes out the 8-byte change made above, but doesn't hurt.

Same here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29744#discussion_r2847698010
PR Review Comment: https://git.openjdk.org/jdk/pull/29744#discussion_r2847700757