Why is LambdaMetafactory 10% slower than a static MethodHandle but 80% faster than a non-static MethodHandle?

[Vladimir Ivanov]

On 2/19/18 5:13 PM, Jochen Theodorou wrote:
> On 19.02.2018 14:31, Vladimir Ivanov wrote:
> [...]
>> CallSites are the best you can get (JITs treat CallSite.target as 
>> constant and aggressively inlines through them), but you have to bind 
>> CallSite instance either to invokedynamic call site or put it into 
>> static final field.
> 
> And that really extends to MutableCallsite? In a dynamic language where 
> you depend on the instance types you cannot do all that much with a 
> non-mutable callsite.

Yes, it covers all flavors of CallSites. In case of 
Mutable/VolatileCallSite, JIT-compiler records a dependency on CallSite 
target value and invalidates all dependent nmethods when CallSite target 
changes. It doesn't induce any overhead at runtime and allows to reach 
peak performance after every CallSite change (due to recompilation), but 
it doesn't favor regularly changing CallSites (manifests as continuous 
recompilations at runtime).

Best regards,
Vladimir Ivanov

> [...]
>> The best thing you can do is to wrap method handle constant into a 
>> newly created class (put it into constant pool or static final field) 
>> and define a method which invokes the method handle constant (both 
>> indy & MH.invokeExact() work). The method should either implement a 
>> method from super-interface or overrides a method from a super-class 
>> (so there's a way to directly reference it at use sites). The latter 
>> is preferable, because invokevirtual is faster than invokeinterface. 
>> (LambdaMetafactory does the former and that's the reason it can't beat 
>> MH.invokeExact() on non-constant MH).
> 
> that is indeed something to try, nice idea. Now finding the time to 
> actually do it :(
> 
> bye Jochen