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

[Evgeny Astigeevich]

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 Andrew,

> If you would like to continue, perhaps we could work on this together, and come up with something we both like. Would you be happy to try that?

Sorry for the late response. I am on a business trip. Yes, I am keen to finish this.
BTW, we have a new `trampoline_call1`: https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L1101. This is a surprise from the project Loom. I'll try  to handle it as well.

> I apologize for my use of words. It was an inappropriate thing to say, and I wish I hadn't said it.

Thank you. Apologies accepted.

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. 

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

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?

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?

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

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