RFR: 8283689: Update the foreign linker VM implementation [v7]

[Jorn Vernee]

On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'foreign-preview-m' into JEP-19-VM-IMPL2
>>  - Remove unneeded ComputeMoveOrder
>>  - Remove comment about native calls in lcm.cpp
>>  - 8284072: foreign/StdLibTest.java randomly crashes on MacOS/AArch64
>>    
>>    Reviewed-by: jvernee, mcimadamore
>>  - Update riscv and arm stubs
>>  - Remove spurious ProblemList change
>>  - Pass pointer to LogStream
>>  - Polish
>>  - Replace TraceNativeInvokers flag with unified logging
>>  - Fix other platforms, take 2
>>  - ... and 11 more: https://git.openjdk.java.net/jdk/compare/3c88a2ef...43fd1b91
>
> src/hotspot/share/opto/callGenerator.cpp line 1131:
> 
>> 1129: 
>> 1130:     case vmIntrinsics::_linkToNative:
>> 1131:     print_inlining_failure(C, callee, jvms->depth() - 1, jvms->bci(),
> 
> Why is it unconditionally reported as inlining failure?

The call that is being processed here is `linkToNative`, and that call is not inlined, so reporting an inlining failure seems correct. We still go through the method handle trampoline stub which loads the actual target from the NativeEntryPoint (`jump_to_native_invoker` in methodHandles_x86.cpp).

It's potentially faster here to generate a runtime call to the underlying invoker/downcall stub if the NativeEntryPoint is constant (i.e. avoid the lookup through NEP in the MH trampoline), but I hadn't gotten to investigating that yet.

>From comparing the benchmark times between this and the old implementation (which generated an inline call), they are not all that different. So it seemed that doing something special here would not save that much time any ways. (but, still would be good to investigate at some point)

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

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