(original) (raw)

On Mar 25, 2015, at 10:38 AM, Vladimir Ivanov <vladimir.x.ivanov@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@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