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

Mikhail Ablakatov mablakatov at openjdk.org
Thu Aug 7 14:34:16 UTC 2025


On Mon, 4 Aug 2025 17:11:59 GMT, Evgeny Astigeevich <eastigeevich at openjdk.org> wrote:

> So you actually have:
> ```
> key -> value
> (trampoline_id1} -> {get_resolve_static_call_stub, {call_B_offset1, call_B_offset2}}
> {trampoline_id2} -> {get_resolve_static_call_stub, {call_C_offset1, call_C_offset2, call_C_offset3}}
> {trampoilen_id3} -> {some_runtime_call, {call_RT_offset1, call_RT_offset2, call_RT_offset3}}
> ```

Am I right assuming you're suggesting to simplify the logic in `auto emit = [&](address dest, const CodeBuffer::Offsets &offsets)` (so the compiler doesn't need to distinguish between runtime and static calls to update the `dest` for the latter) by storing the effective `dest` addresses in the `_shared_trampoline_requests` dictionary as a part of the value?

It seems to me this should work. It unifies emission logic by storing more data up front, when a shared trampoline is requested. However, I'm not sure there's a clearly better approach here. This design leads to some duplication - for instance, `trampoline_id3` should match `some_runtime_call`, if I understand correctly. Taking this into account, I'd suggest keeping the current approach and not proceeding with the alternative implementation described above. 

> IMO based on `SharedRuntime::resolve_helper`, we can have shared trampolines for `relocInfo::opt_virtual_call_type` and `relocInfo::virtual_call_type`. Their trampolines have the corresponding resolver set. I don't see we write anything specific to a call site into a trampoline.

I can see this being implemented as a follow-up PR. For now, I suggest to establish the core mechanism by supporting static call trampolines only. If your assumption holds, a follow-up patch should turn up rather easy to implement and review.

Let me know if you spot anything in the proposed design that may hinder future extensions.

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

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


More information about the hotspot-dev mailing list