On Tue, 10 May 2022 19:21:58 GMT, Vladimir Ivanov <vliva...@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

Reply via email to