RFR: 8302745: sp > unextended_sp for interpreted to interpreted calls going through method handle linker [v2]
Dean Long
dlong at openjdk.org
Thu Feb 26 08:42:24 UTC 2026
On Wed, 25 Feb 2026 11:08:38 GMT, Anton Artemov <aartemov at openjdk.org> 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
More information about the serviceability-dev
mailing list