----- Mail original -----
> De: "Vladimir Ivanov" <vladimir.x.iva...@oracle.com>
> À: "Jochen Theodorou" <blackd...@gmx.org>, "Da Vinci Machine Project" 
> <mlvm-dev@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

mlvm-dev mailing list

Reply via email to