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

[Remi Forax]

----- Mail original -----
> De: "Vladimir Ivanov" <vladimir.x.ivanov at oracle.com>
> À: "Jochen Theodorou" <blackdrag at gmx.org>, "Da Vinci Machine Project" <mlvm-dev at openjdk.java.net>
> Envoyé: Lundi 19 Février 2018 15:47:45
> Objet: Re: Why is LambdaMetafactory 10% slower than a static MethodHandle but 80% faster than a non-static MethodHandle?

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

For the shake of completeness, i will just add that this is only true for callsites that are attached to a bytecode, i.e. the ones that are returned by a bootstrap method, if you allocate and store a CallSite in a local variable, it will not magically turn itself to a constant.

And that the VM trusts you, i.e. if you mutate a MutableCallSite too frequently (by example at each call), it will be dog slow because the JIT will optimize/deoptimize at each call.

> 
> Best regards,
> Vladimir Ivanov
> 

Rémi