On Wed, 25 Feb 2026 11:08:38 GMT, Anton Artemov <[email protected]> wrote:
>> Hi, please consider the following changes:
>>
>> This is 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.
>
> 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.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29744#issuecomment-3965013398
