[13] RFR (S): 8192001: C2: inlining through dispatching MH linkers ignores speculative type of the receiver

[Vladimir Ivanov]

Thanks for reviews, Roland & Tobias.

On 25/01/2019 01:28, Remi Forax wrote:
> thanks for fixing that,
> it was a blocker in my attempt to implement a Stream like API using method handles :)
Let me know about your experience. Completely forgot where the request 
came from :-)

Best regards,
Vladimir Ivanov

> ----- Mail original -----
>> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
>> À: "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
>> Envoyé: Vendredi 25 Janvier 2019 02:56:39
>> Objet: [13] RFR (S): 8192001: C2: inlining through dispatching MH linkers ignores speculative type of the receiver
> 
>> http://cr.openjdk.java.net/~vlivanov/8192001/webrev.00/
>> https://bugs.openjdk.java.net/browse/JDK-8192001
>>
>> When inlining through MethodHandle calls, C2 can improve inlining
>> decisions by taking speculative types into account (availability of type
>> information is addressed by JDK-8191998 [1]).
>>
>> There's no profiling performed at method handle linker call sites
>> (MethodHandle::linkTo*), but type info can flow from other sources.
>>
>> As an example, consider the following case:
>>
>>    class A           { void m() { ... } }
>>    class B extends A { void m() { ... } }
>>
>>    MH = LOOKUP.findVirtual(A.class, "m", ...);
>>
>>    void test(A o) throws Throwable {
>>      MH.invokeExact(o);
>>    }
>>
>>    test(new B());
>>
>> Before (no inlining):
>> 251   12   !b        TestMH::test (21 bytes)
>>    ...
>>    @ 16   TestMH1$A::m (1 bytes)   virtual call
>>
>> After (guarded inlining):
>> 251   12   !b        TestMH::test (21 bytes)
>>    ...
>>    @ 16   TestMH1$B1::m (1 bytes)   inline (hot)
>>       \-> TypeProfile (-1/6701 counts) = TestMH1$B1
>>
>> Testing: hs-precheckin-comp, hs-tier1, hs-tier2.
>>
>> Best regards,
>> Vladimir Ivanov
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8192001