[10] RFR (M): 6986483: CHA: optimize calls through interfaces

[Vitaly Davidovich]

On Thu, Feb 16, 2017 at 3:00 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
>
> This is a nice surprise :-)

+1 - great work Vladimir! I didn't know C1 handled this already - always
thought it's no better than C2 in any performance aspect :).

A bit premature to ask perhaps, but could this conceivably be backported to
Java 9?

>
>
> I happened to be separately looking at this area, analysing the
> performance of interfaces/abstract classes to apply a certain
> implementation technique to avoid going megamorphic.
>
> I concluded that the implementation technique was not viable, but with
> your patch i think i can revive it and perform more detailed analysis.
>
> Based on my benchmark the performance improvement looks good.
>
> Thanks!
> Paul.
>
> > On 14 Feb 2017, at 10:51, Vladimir Ivanov <vladimir.x.ivanov at oracle.com>
> wrote:
> >
> > http://cr.openjdk.java.net/~vlivanov/6986483/webrev.00/
> > https://bugs.openjdk.java.net/browse/JDK-6986483
> >
> > Proposed change adds CHA support in C2 for interface calls.
> >
> > Consider the following hierarchy:
> >
> >  interface Intf { m(); }
> >  class C implements Intf { public m() { ... } }
> >  class C1 extends C { /* doesn't override m() */ }
> >  ...
> >  class Cn extends C { /* doesn't override m() */ }
> >
> > Call site: invokeinterface Intf.m() ...
> >
> > If Intf were an abstract class, CHA could deduce that Intf::m() can be
> replaced with C::m(), but it doesn't work for interfaces. Verifier doesn't
> check interface types in bytecode, so CHA can't assume the receiver
> implements Intf.
> >
> > CHA in C1 handles such call sites for interfaces with a single
> implementor. It replaces invokeinterface Intf.m() with invokevirtual C.m()
> guarded by a subtype check (instanceof C). C2 doesn't do that and this
> request is about adding that. Type profiling doesn't help here (the call
> site is usually megamorphic), so C2 can't inline it.
> >
> > The proposed implementation is similar to C1, except that the code
> deoptimizes when subtype check fails and ICCE is thrown from the
> interpreter.
> >
> > While working on it, I spotted and fixed a couple of inefficiencies in
> C1 implementation:
> >
> >  (1) dependency context being used was broader than necessary - resolved
> instead of declared interface (hence, possibility of unnecessary
> invalidations);
> >
> >  (2) didn't work for interfaces w/ any default methods: CHA doesn't
> support default methods at the moment, so what matters is whether Intf::m()
> is default or not and not whether Intf has *any* concrete methods.
> >
> > Testing: unit tests on CHA, JPRT, RBT (hs-comp-tier0, in progress),
> LogCompilation tool.
> >
> > Thanks!
> >
> > Best regards,
> > Vladimir Ivanov
>
> --
Sent from my phone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170222/580fd0da/attachment.html>