RFR: 8359359: AArch64: share trampolines between static calls to the same method [v8]

[Mikhail Ablakatov]

On Mon, 10 Nov 2025 22:19:19 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

>> Mikhail Ablakatov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge commit 'f6f87bb6759c86d941453a1776e8abfdffc48183' into 8359359
>>  - the only trampoline in ArrayCopyStub is never shared
>>  - fixup: a shared trampoline must branch to a statically bound method
>>  - share static call trampolines generated by C1 as well
>>  - assert callee is nullptr for runtime calls
>>  - assert that call sites offsets aren't missing
>>  - cleanup: rephrase comments in macroAssembler_aarch64.hpp
>>  - Merge commit 'fd29677479797956e0d205b5ce6e7cb9ad407bd1' into 8359359
>>  - Merge commit '41520998aa8808452ee384b213b2a77c7bad668d'
>>  - remove implementation-dependent logic from emit_shared_trampolines()
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/f6f87bb6...871903f4
>
> test/hotspot/jtreg/compiler/sharedstubs/SharedStaticCallTrampolineTest.java line 121:
> 
>> 119:                 .filter(addr -> Collections.frequency(trampolineAddrs, addr) == 1)
>> 120:                 .collect(Collectors.toList());
>> 121:         if (uniqueTrampolineAddrs.size() == 0) {
> 
> Should we expect this to be 1? Possible values: 0, 1 or 3?
> 0 - incorrect mapping of a call site
> 1 - everything is correct
> 3 - sharing does not work

Yes, the code expects this to be 1. I'd argue that testing for 3 here would duplicate the check already performed above ([line 119](https://github.com/openjdk/jdk/pull/25954/files#diff-96cb53c21e0d1344a4359e395671d20c5c4dc8493a87c7716936f35258f939cfR119)).

Currently, `checkOutput(OutputAnalyzer)` explicitly checks for two kinds of incorrect behaviors:

1. No trampoline stubs shared across static calls
2. A trampoline stub is shared while it should not be

If neither of these issues is detected, the code implicitly treats the behavior as correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2565648787