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

Hi,

> Thank you for the details. They helped a lot. Most of them are aligned with what I've read in sources and seen in a debugger.
> 
> > trampoline call:
> > ...
> > It has the advantages that it can
> > reach anywhere in the AArch64 address space.
> 
> I created a bug: https://bugs.openjdk.java.net/browse/JDK-8286314. With small CodeCache, trampolines are not created for out of range targets which are outside CodeCache.

Oh! Thank you. I wonder why we never saw that one before. I guess because we don't normally have a small-enough CodeCache.

> I wanted to say that trampoline calls support link-time optimization: replacing a trampoline call by a direct one. Link-time optimization are not applied to far calls at the moment. Could I write in this way?

Sounds good.

> BTW, if we are not going to relocate code (this is true for non-nmethod), we can patch far calls as well. During copying code to CodeCache, we can:
> 
>     * keep `adrp;add` but replace `blr` with `bl`
> 
>     * replace `adrp;add;blr` with  `nop;nop;bl`
> 
> What do you think?

Either sounds fine. I guess the latter will be a bit more efficient.

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

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