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

[Evgeny Astigeevich]

On Thu, 7 Aug 2025 14:31:09 GMT, Mikhail Ablakatov <mablakatov at openjdk.org> wrote:

> Am I right assuming you're suggesting to simplify ...

Yes.

> 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.

There should not be any duplication. Why do you think so?

Let's revisit the example. This time `A` has three calls of  `Arrays.hashCode`. For large arrays we will use the stub `StubRoutines::aarch64::large_arrays_hashcode`.

Your implementation:

key -> value
{B} -> {relocInfo::static_call_type, {call_B_offset1, call_B_offset2}}
{C} -> {relocInfo::static_call_type, {call_C_offset1, call_C_offset2, call_C_offset3}}
{StubRoutines::aarch64::large_arrays_hashcode} -> {relocInfo::runtime_call_type, {call_RT_offset1, call_RT_offset2, call_RT_offset3}}


Mine proposal:

key -> value
(B} -> {get_resolve_static_call_stub, {call_B_offset1, call_B_offset2}}
{C} -> {get_resolve_static_call_stub, {call_C_offset1, call_C_offset2, call_C_offset3}}
{StubRoutines::aarch64::large_arrays_hashcode} -> {StubRoutines::aarch64::large_arrays_hashcode, {call_RT_offset1, call_RT_offset2, call_RT_offset3}}


I don't see any duplication.

> Taking this into account, I'd suggest keeping the current approach and not proceeding with the alternative implementation described above.

I dont understand what you mean "the current approach". Do you mean using `Pair` and checking `relocInfo::relocType`?

`Pair` obfuscates what is stored inside it. IMO this reduces readability of the program. `SharedTrampolineRequest` clearly states its purpose and the purpose of its members.

> I can see this being implemented as a follow-up PR.
I am ok with this.

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

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