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

[Mikhail Ablakatov]

On Wed, 25 Jun 2025 09:19:20 GMT, Andrew Haley <aph 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.
>
> One thing that looks a little odd: why do you maintain two separate lists and two sets of trampoline stub handlers?

Hi @theRealAph , thank you for taking a look.

JIC, these are hash tables with (target address; list of requests (call site offsets)) as (k;v) pairs. I've considered unifying the two hash tables. The problem here is the keys. We need a way to distinguish between runtime call keys and static call keys as we iterate through the table. We could use `CodeCache::is_non_nmethod(address addr)` for that but this would only work when segmented code cache is enabled as far as I understand.

We could use something like `Pair<callKind, address>` for keys instead and use the `first` to distinguish between runtime and static calls. I'd need to extend `template<...> class Pair` so it properly supports hashing and comparison (at least equality) for this to work.

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

PR Comment: https://git.openjdk.org/jdk/pull/25954#issuecomment-3004652098