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
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev