On Fri, 13 Mar 2026 09:00:19 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 with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains four additional > commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into > JDK-8302745-unextended-sp-less-than-sp > - 8302745: Don't touch ARM code. > - 8302745: Addressed reviewer's comments. > - 8302745: Fix for sp > unextended_sp for x86 and aarch64. Regarding the possibility of esp being lower than sp and thus allowing reads or writes past the end of the stack, that would be a bug unless the ABI guarantees a red zone or safe zone that can be scribbled on, because normally we could expect asynchronous signal handlers to trash that memory at any time. I'm not aware of aarch64 guaranteeing any safe zone past the end of the stack. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29744#issuecomment-4059368500
