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. On x86, last_sp and sender_sp are essentially the same. Which means the method handle linker adjustment can make last_sp point beyond SP, yet safe_for_sender only cares about sender_sp/unextended_sp, not last_sp. The more I look at this, the more I feel like the proposed change is not the way to go. I do not agree with the comments in the JDK-8302320 PR discussion that we should change unextended_sp rather than fix safe_for_sender. I am in the opposite camp: fix only safe_for_sender. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29744#issuecomment-4070540389
