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

Nils Eliasson nils.eliasson at oracle.com
Tue Jan 29 14:03:25 UTC 2019


Hi Vladimir,

A really good improvement, and I really like the test, excellent coverage.

Reviewed,

// Nils


On 2019-01-25 22:27, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/6986483/webrev.01/
> https://bugs.openjdk.java.net/browse/JDK-6986483
>
> Another candidate for revival. At that time it was reviewed, but 
> integration was blocked pending another bug fix. Now the fix is in.
>
> Quote from original review request [1]:
>
> "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: hs-precheckin-comp, hs-tier1, hs-tier2
>
> Best regards,
> Vladimir Ivanov
>
> [1] 
> https://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2017-February/025630.html


More information about the hotspot-compiler-dev mailing list