RFR: 8285487: Do not generate trampolines for runtime calls if they are not needed [v3]

[Xin Liu]

On Fri, 29 Apr 2022 22:37:25 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Yes, we try to bypass trampolines during moving code into `CodeCache`:
>> 
>> void Relocation::pd_set_call_destination(address x) {
>>   assert(is_call(), "should be a call here");
>>   if (NativeCall::is_call_at(addr())) {
>>     address trampoline = nativeCall_at(addr())->get_trampoline();
>>     if (trampoline) {
>>       nativeCall_at(addr())->set_destination_mt_safe(x, /* assert_lock */false);
>>       return;
>>     }
>>   }
>>   MacroAssembler::pd_patch_instruction(addr(), x);
>>   assert(pd_call_destination(addr()) == x, "fail in reloc");
>> }
>> 
>> void NativeCall::set_destination_mt_safe(address dest, bool assert_lock) {
>> ....
>>   ResourceMark rm;
>>   int code_size = NativeInstruction::instruction_size;
>>   address addr_call = addr_at(0);
>>   bool reachable = Assembler::reachable_from_branch_at(addr_call, dest);
>> ...
>>   // Patch the constant in the call's trampoline stub.
>>   address trampoline_stub_addr = get_trampoline();
>> ...
>>   // Patch the call.
>>   if (reachable) {
>>     set_destination(dest);
>>   } else {
>>     assert (trampoline_stub_addr != NULL, "we need a trampoline");
>>     set_destination(trampoline_stub_addr);
>>   }
>> ...
>> }
>
> So my assumption that `trampoline_call()` could be used for call outside CodeCache is wrong (and the method's comment is correct). I looked on few places where runtime call is generated and `trampoline_call()` indeed is used only for CodeCache (at least in places are looked on):
> https://github.com/openjdk/jdk/blob/master/src/hotspot/cpu/aarch64/aarch64.ad#L3858
> 
> My points 1. and 2. are void. 
> 
> Thank you for answering my questions 3. and 4.
> 
> That also explains your `need_trampoline` code change.
> 
> You answered all my questions. Please, do latest merge and updates if needed so I can review final changes.

hi, @vnkozlov , @eastig 
> I would like to know why trampoline_call() could be used for relocInfo::virtual_call_type and relocInfo::opt_virtual_call_type (based on assert). They should be inside CodeCache and you don't need trampoline for it. Right?

I take a look at `vmIntrinsics::does_virtual_dispatch`, it looks like there are 2 special intrinsics could be virtual. 
when c2 calls runtime stubs for them, we actually give up this optimization, right?  Is it possible to include those 2 reloc types as well?

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

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