[prev in list] [next in list] [prev in thread] [next in thread]
List: openjdk-hotspot-compiler-dev
Subject: Re: [9] Preliminary RFR (M): Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls
From: Christian Thalinger <christian.thalinger () oracle ! com>
Date: 2015-03-30 18:51:01
Message-ID: 9D307D39-6867-47A2-8438-76434442FA6C () oracle ! com
[Download RAW message or body]
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@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
[Attachment #3 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space;" class="">I think it's about time to remove \
this:<div class=""><br class=""></div><div class=""><pre style="background-color: \
rgb(238, 238, 238);" class=""> \
guarantee(!target->is_method_handle_intrinsic(), "should not happen"); // XXX \
remove </pre><div class=""><br class=""></div><div class="">I should have removed it \
before the initial integration :-)</div><div class=""><br \
class=""></div><div><blockquote type="cite" class=""><div class="">On Mar 25, 2015, \
at 10:38 AM, Vladimir Ivanov <<a href="mailto:vladimir.x.ivanov@oracle.com" \
class="">vladimir.x.ivanov@oracle.com</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><a \
href="http://cr.openjdk.java.net/~vlivanov/8072008/webrev.00" \
class="">http://cr.openjdk.java.net/~vlivanov/8072008/webrev.00</a><br \
class="">https://bugs.openjdk.java.net/browse/JDK-8072008<br class=""><br \
class="">I'd like to get early feedback on the approach I chose.<br class="">So far, \
only x86 is supported. Other platforms are WIP.<br class=""><br class="">The idea is \
to get rid of MH.invokeBasic/linkTo* linkers when receiver/MemberName is constant, \
but VM doesn't inline target method.<br class=""><br class="">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.<br class=""><br \
class="">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).<br class=""><br class="">Example:<br class=""> MemberName mn = ...; \
// compile-time constant<br class=""> MethodHandle.linkToStatic(..., mn)<br \
class=""><br class=""> callq 0x0000000109cb1900 ; OopMap{off=28}<br \
class=""> &nbs \
p; ; \
*invokestatic linkToStatic<br class=""> \
&n \
bsp; ; - \
Test::invokeStatic@3 (line 108)<br class=""> \
&n \
bsp; ; \
{static_call T.f1}<br class=""><br class="">It's call to MethodHandle.linkToStatic on \
bytecode level, but in generated code it's a direct call to T.f1.<br class=""><br \
class="">I enhanced diagnostic output to provide additional information call site \
targets when additional info is present.<br class=""><br class="">Also, for testing \
purposes, I introduced 2 new methods for whitebox testing:<br class=""> - \
WhiteBox::clearInlineCaches<br class=""> - WhiteBox::deoptimize<br class=""><br \
class="">Testing: JPRT, java/lang/invoke, nashorn, octane<br class=""><br \
class="">Thanks!<br class=""><br class="">Best regards,<br class="">Vladimir \
Ivanov<br class=""></div></blockquote></div><br class=""></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic