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

[Vladimir Kozlov]

Seems fine to me.

thanks,
Vladimir K

On 2/14/17 10:51 AM, Vladimir Ivanov 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