RFR: 8359359: AArch64: share trampolines between static calls to the same method [v4]
Evgeny Astigeevich
eastigeevich at openjdk.org
Tue Aug 12 22:27:14 UTC 2025
On Tue, 12 Aug 2025 15:28:14 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 three additional commits since the last revision:
>
> - cleanup: update copyright headers
> - Make the value type of the dictionary a struct instead of Pair typedef
> - Remove share_rc_trampoline_for and share_sc_trampoline_for
src/hotspot/cpu/aarch64/codeBuffer_aarch64.cpp line 66:
> 64: if (rtype == relocInfo::static_call_type) {
> 65: dest = SharedRuntime::get_resolve_static_call_stub();
> 66: }
You are pulling details of implementation, use of `SharedRuntime::get_resolve_static_call_stub` for unlinked static calls. There is no need for this.
It was: create a trampoline to the destination and relocation infos for all places in code which will share it. This is simple. It does not rely on any information about call sites.
Now it is: we are creating a trampoline for an unlinked static call, it must have `get_resolve_static_call_stub` as a destination. Why should we have this? `Address` will always contain a correct destination set by a compiler. So we do double job, we throw away a target set by a compiler.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/25954#discussion_r2271423605
More information about the hotspot-dev
mailing list