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

[Anton Artemov]

On Thu, 26 Feb 2026 08:39:20 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Anton Artemov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8302745: Don't touch ARM code.
>>  - 8302745: Addressed reviewer's comments.
>
> Hi Anton.  Sorry, maybe I'm missing something, but this looks wrong.  My understanding is that the aarch64 interpreter frame goes through the following stages:
> 1. new frame, sp includes max_stack and 16 byte alignment, sp <= esp
> 2. call to interpreter, r19=sp snapshot, sp bumped to esp - extra_locals
>     Depending on size of caller max_stack and callee extra_locals, adjusted sp can now be either less or greater than
>     r19, so we can't reliably assert any relationship between the two
> 3. method handle invoke, esp += 1 for membername
> As far as I can tell, this PR changes the meaning of unextended_sp be an aligned version of esp.
> Using this value on method return means SP no longer includes worst case stack size based on max_stack,
> so growing esp can now exceed SP.  But we should have asserts for that, so I probably got something wrong.

@dean-long 
> Hi Anton. Sorry, maybe I'm missing something, but this looks wrong. My understanding is that the aarch64 interpreter frame goes through the following stages:

Hi Dean, thanks for taking a look. You point n2 is related to [8294152](https://bugs.openjdk.org/browse/JDK-8294152), and indeed, with `r19` keeping a snapshot of `sp`, one can't say anything about relation of that snapshot value and the adjusted `sp`.

With  `r19` keeping an aligned version of `esp ` a relationship can be established, but as you mention in point 3, it looks like `esp` can now exceed the `sp`. I did not find any asserts for that, but now added a few myself in the assembly code, and yes, a few tests in tier1 hit them. So this fix is not correct. I will put it back to draft for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/29744#issuecomment-3983005303