On Wed, 11 May 2022 11:06:51 GMT, Jorn Vernee <jver...@openjdk.org> wrote:

>> 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 appendix argument (`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)

I've filed: https://bugs.openjdk.java.net/browse/JDK-8286588


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

Reply via email to