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

[Remi Forax]

Hi Vladimir,
thanks for fixing that,
it was a blocker in my attempt to implement a Stream like API using method handles :)

Rémi 

----- 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