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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Wed Mar 25 17:38:54 UTC 2015


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