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

[forax at univ-mlv.fr]

Hi Vladimir,
thanks for the answer,
i guess i will have to move one project to jdk9 earlier than expected, not a big deal.

Best regards,
Rémi

----- Mail original -----
> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoyé: Vendredi 30 Octobre 2015 09:57:48
> Objet: Re: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for recursive indy/MH.invoke* calls
> 
> Remi, very unlikely. I'm afraid it's too late to get it into for any
> forthcoming 8u release. It is not considered as a critical bug, so it
> would be really hard to get it into.
> 
> Best regards,
> Vladimir Ivanov
> 
> On 10/30/15 11:36 AM, Remi Forax wrote:
> > Thanks Vladimir,
> > this fix an important regression between jdk7 (before update 40) and jdk8.
> >
> > I know that this can be complicated but does this patch can be backported
> > to an update of 8 ?
> >
> > regards,
> > Rémi
> >
> > ----- Mail original -----
> >> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> >> À: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> >> Envoyé: Jeudi 29 Octobre 2015 22:36:12
> >> Objet: [9] RFR (L): 8072008: Emit direct call instead of linkTo* for
> >> 	recursive indy/MH.invoke* calls
> >>
> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/
> >> https://bugs.openjdk.java.net/browse/JDK-8072008
> >>
> >> NB! It touches aarch64 & ppc code, so I'd like to hear from the
> >> maintainers whether the changes are fine.
> >>
> >> To simplify review process, the changes can be split in 2 parts.
> >>
> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.reloc/
> >>
> >> Platform-dependent changes in macro assembler to switch from relocation
> >> types to relocation instances, and attach pre-resolved method to call
> >> sites in generated code.
> >>
> >> http://cr.openjdk.java.net/~vlivanov/8072008/webrev.01/hotspot.attach/
> >> High-level adjustments in C2 and test cases.
> >>
> >> Overview
> >>
> >> There's a performance problem with inlining through
> >> MH.linkTo*/invokeBasic linkers. When MemberName/receiver is constant and
> >> VM sees the target method during compilation, but decides not to inline
> >> (e.g. recursive inlining), a call to linker is generated, but more
> >> optimal code shape is to call target method directly.
> >>
> >> The problem with substituting a linker call by a direct/virtual call is
> >> that call site resolution logic relies on bytecode info (see
> >> SharedRuntime::resolve_{static,opt_virtual,virtual}_call_C and
> >> SharedRuntime::find_callee_info_helper). But on bytecode level symbolic
> >> reference points to the linker method, which doesn't tell anything about
> >> target method.
> >>
> >> The fix is to attach additional metadata (Method*) to the call site, so
> >> VM can use it instead of inspecting bytecode when linking the call site.
> >> The Method* is placed in relocation table (for static_call,
> >> opt_virtual_call, and virtual_call relocation types) and contains a
> >> Method* the call site is resolved to by JIT compiler (_method from a
> >> call IR node).
> >>
> >> It is used only in C2 generated code.
> >>
> >> Example:
> >>
> >>     MemberName mn = ... <<T.f1>> ... ; // compile-time constant
> >>     MethodHandle.linkToStatic(..., mn)
> >>
> >> compiles to:
> >>
> >>     callq  0x0000000109cb1900  ; OopMap{off=28}
> >>                                ; *invokestatic linkToStatic
> >>                                ; - Test::invokeStatic at 3 (line 108)
> >>                                ; {static_call T.f1}
> >>
> >> It's a call to MethodHandle.linkToStatic on bytecode level, but in
> >> generated code it's a direct call to T.f1.
> >>
> >> For testing purposes, 2 new WhiteBox methods are introduced:
> >>     - clearInlineCaches
> >>     - deoptimize
> >>
> >> They are used in unit tests (test/compiler/jsr292/NonInlinedCall/*)
> >> which stresses new code shapes.
> >>
> >> WhiteBox changes require some adjustments in build scripts, since
> >> @HotSpotIntrinsicCandidate isn't part of JDK8. But it will be fixed
> >> separately (the idea is to start building wb.jar with JDK9).
> >>
> >> Testing: JPRT, java/lang/invoke, nashorn, octane
> >>
> >> Thanks!
> >>
> >> Best regards,
> >> Vladimir Ivanov
> >>
>