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

[Vladimir Ivanov]

Thanks, Vladimir.

Best regards,
Vladimir Ivanov

On 2/15/17 11:38 PM, Vladimir Kozlov wrote:
> 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