RFR: 8286058: AArch64: clarify uses of MacroAssembler::trampoline_call [v2]

[Andrew Haley]

On Thu, 5 May 2022 22:49:43 GMT, Evgeny Astigeevich <duke at openjdk.java.net> wrote:

>> `MacroAssembler::trampoline_call` is for generating calls of targets which are inside CodeCache and can have relocInfo types: `runtime_call_type`, `opt_virtual_call_type`, `static_call_type` or `virtual_call_type`.
>> This PR updates the description of the function and adds additional asserts.
>> Tested a fastdebug build:
>> - `gtest`: Passed
>> - `tier1`: Passed
>
> Evgeny Astigeevich has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix assert message

On 5/6/22 10:42, Evgeny Astigeevich wrote:
 > ***@***.**** commented on this pull request.
 >
 > --------
 >
 > In src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp <https://github.com/openjdk/jdk/pull/8564#discussion_r866663630>:
 >
 >> +  // If the distance to the address can exceed the branch range
 > +  // (128M for the release build, 2M for the debug build; see branch_range definition)
 > +  // for direct calls(BL), a special code with BR (trampoline) is put in the stub code section.
 > +  // The call is redirected to it. When CodeBuffer is copied to CodeCache, the distance to
 > +  // callee's address is checked to bypass the trampoline by replacing the call of the trampoline
 > +  // with the call of the target.
 > +  //
 > +  // Trampoline_call is most suitable for calls of Java methods. Java calls callees can be changed
 > +  // to the interpreter or different versions of a compiled method. Those callees can be
 > +  // near-distant or far-distant. Trampoline_call supports switching between near-distant callees
 > +  // and far-distant callees by having a reserved trampoline. The trampoline is only used if needed.
 > +  //
 > +  // The code for runtime calls can also be generated with far_call. For possible far-distant callees
 > +  // far_call does not use the stub code section for additional code. It inserts the code at a call site.
 > +  // This prevents the call from optimization to a direct call when the code is copied to CodeCache.
 > +  //
 >
 >     "This prevents the call from optimization to a direct cal" is completely wrongl
 >
 > If I am wrong, could you please point me at the place where 'adrp, add, bl' is optimized?

Ah, I think I see. Are you saying that a far call is not
converted to a direct call when the code is moved into the code
cache, even if a direct call might reach its target? And that far
calls do not need a trampoline.  OK.

 >     As far as I can tell it is nonsense.
 >
 > Could you please be more constructive?

I did not understand what you were saying. And I wrote all of the
code you're trying to describe.

 >     It introduces pointless confusing terminology such as "far-distant" and "near-distant".
 >
 > Please, offer your variant. There is no standard terminology:

The names we already use are direct call, far call, and
trampoline call.  Direct calls can reach +/- 128M, so unless our
code cache is < 128M we can't always use them. Far calls have a
range of 4G, so can be reach anything in the code cache, but not
C++ code in a shared library. Trampoline calls can reach anywhere
in the address space.

When we're generating code in C2, we can always generate a
trampoline, and trampolines can reach anywhere. Outside C2 we may
not have a stub section so we can't generate a trampoline.
However, we can generate a far call, which can reach anywhere in
the code cache, but not the entire address space.

When patching code at runtime we are restricted by the rules in
the Arm ARM. We can replace a call with another call, but we
can't, for example, replace an ADRP with a CALL, or a CALL with
an ADRP.

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

PR: https://git.openjdk.java.net/jdk/pull/8564