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
mlvm-dev mailing list

Reply via email to