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

[Evgeny Astigeevich]

On Mon, 2 May 2022 23:53:19 GMT, Xin Liu <xliu at openjdk.org> wrote:

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

Hi Xin(@navyxliu),

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

What optimization are you referring to?

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

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