[9] Preliminary RFR (M): Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls

Vladimir Kozlov vladimir.kozlov at oracle.com
Wed Mar 25 21:30:32 UTC 2015

Why JIT have to generate calls to linkToStatic() and not directly to 
T.f1() when it knows already what is called?

What about C1 changes?

Vladimir K

On 3/25/15 10:38 AM, Vladimir Ivanov 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

More information about the hotspot-compiler-dev mailing list