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

[Evgeny Astigeevich]

On Wed, 2 Jul 2025 15:56:28 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

>> Modify the C2 compiler to share trampoline stubs between static calls that resolve to the same callee method. Since the relocation target for all static calls is initially set to the static call resolver stub, the call's target alone cannot be used to distinguish between different static method calls. Instead, trampoline stubs should be shared based on the actual callee.
>> 
>> The `SharedTrampolineTest.java` was designed to verify the sharing of trampolines among static calls. However, due to imprecise log analysis, the test currently passes even when trampolines are not shared. Additionally, comments within the test suggest ambiguity regarding whether it was intended to assess trampoline sharing for static calls or runtime calls. To address these issues and eliminate ambiguity, this patch renames and updates the existing test. Furthermore, a new test is introduced, using the existing one as a foundation, to accurately evaluate trampoline sharing for both static and runtime calls.
>> 
>> This has passed tier1-3 and jcstress testing on AArch64.
>
> Mikhail Ablakatov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Lift the vm.opt.TieredCompilation == null requirement from the tests
>  - Combine the two shared trampoline request hash tables

src/hotspot/share/asm/codeBuffer.hpp line 550:

> 548:   typedef Pair<TrampolineCallKind, address> SharedTrampolineRequestKey;
> 549:   typedef ResizeableResourceHashtable<SharedTrampolineRequestKey, Offsets, AnyObj::C_HEAP,
> 550:                                       mtCompiler>

You can keep using `address` as a key. I don't think `ciMethod*` can be a runtime call target. If we keep using `address` as a key we don't need to define a hash function. 
A type of a call can be stored as data with offset.

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

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