[9] Preliminary RFR (M): Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls
Christian Thalinger
christian.thalinger at oracle.com
Mon Mar 30 18:51:01 UTC 2015
I think it’s about time to remove this:
guarantee(!target->is_method_handle_intrinsic(), "should not happen"); // XXX remove
I should have removed it before the initial integration :-)
> On Mar 25, 2015, at 10:38 AM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>
> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.00
> https://bugs.openjdk.java.net/browse/JDK-8072008
>
> I'd like to get early feedback on the approach I chose.
> So far, only x86 is supported. Other platforms are WIP.
>
> The idea is to get rid of MH.invokeBasic/linkTo* linkers when receiver/MemberName is constant, but VM doesn't inline target method.
>
> The problem with substituting a linker call with a direct/virtual call is that call site resolution relies on bytecode info (see SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C). But on bytecode level the call site refers to linker method, which is almost useless.
>
> The idea of the fix is to attach additional metadata (Method*) to the call site, so VM can use it instead of querying bytecode. The metadata is placed in relocation table (static_call, opt_virtual_call, virtual_call relocation types) and contains a Method* the call site is resolved to by JIT compiler (_method from a call IR node).
>
> Example:
> MemberName mn = ...; // compile-time constant
> MethodHandle.linkToStatic(..., mn)
>
> callq 0x0000000109cb1900 ; OopMap{off=28}
> ; *invokestatic linkToStatic
> ; - Test::invokeStatic at 3 (line 108)
> ; {static_call T.f1}
>
> It's call to MethodHandle.linkToStatic on bytecode level, but in generated code it's a direct call to T.f1.
>
> I enhanced diagnostic output to provide additional information call site targets when additional info is present.
>
> Also, for testing purposes, I introduced 2 new methods for whitebox testing:
> - WhiteBox::clearInlineCaches
> - WhiteBox::deoptimize
>
> Testing: JPRT, java/lang/invoke, nashorn, octane
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20150330/9ffc2dfc/attachment.html>
More information about the hotspot-compiler-dev
mailing list