RFR: 8267807: C2: Downcast receiver to target holder during inlining

[Vladimir Ivanov]

On Wed, 2 Jun 2021 23:31:42 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> So, CHA is still kept conservative when interface types on receiver are encountered. 
>> Currently, only single implementor case is optimised, but there are proper receiver subtype checks in place.
>> 
>> It should be quite straightforward to relax aforementioned constraints on receiver types (only classes, no interfaces), but then we would require additional receiver subtype check accompanying `Compile::optimize_virtual_call()` calls.
>
> Anyway, as a defense in depth measure, we could still insert receiver subtype check when CHA returns a default method and hope that the check will go away once the type system better tracks interface types. Though the subtype check against an interface can be quite expensive, I don't expect any performance regressions considering CHA hasn't optimized default methods before.

Evidently, it's not the whole story :-) Otherwise, we wouldn't have needed downcasts at all.

It becomes more interesting when CHA discovers unique concrete method under `REFC`:

3a. `invokevirtual   C.m RECV => J.m ABSTRACT, unique = K.m DEFAULT, K <: J` (`I.m` - resolved method, `REFC = C`)
3b. `invokeinterface I.m RECV => J.m ABSTRACT, unique = K.m DEFAULT, K <: J` (`I.m` - resolved method, `REFC = I`)

(Moreover, 3b is equivalent to 3a since `actual_receiver` has to be a class and
not an interface. Otherwise, CHA fails fast. There's additional case - unique
implementor - but it strength-reduces invokeinterface to invokevirtual.)

It is guaranteed that `RECV <: C <: J` and `RECV <: I < J`, but there's nothing except the CHA itself that 
proves `RECV <: J` always holds.

In 3a and 3b case, CHA iterates all the subtypes under statically known receiver type
(`actual_receiver`, subtype of `I`/`C`). Assuming the analysis is correct, it proves
that `RECV <: J`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4212