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

Vladimir Ivanov vladimir.x.ivanov at oracle.com
Fri Jan 25 21:27:40 UTC 2019


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