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
