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

[Vitaly Davidovich]

On Wed, Feb 22, 2017 at 9:47 AM, Vladimir Ivanov <
vladimir.x.ivanov at oracle.com> wrote:

> Vitaly,
>
> A bit premature to ask perhaps, but could this conceivably be backported
>> to Java 9?
>>
> Yes, once it gets enough testing in jdk10 repo I'll consider backporting
> it into upcoming 9u release.
>
> No chances to get it into jdk9 GA though.
>
Sounds great - thanks!

>
> Best regards,
> Vladimir Ivanov
>
>
>>     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 <mailto: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/c3505082/attachment.html>