On 02/13/2011 07:00 PM, fo...@x9c.fr wrote:
Le 13 févr. 2011 à 12:55, Rémi Forax a écrit :
On 02/13/2011 10:07 AM, fo...@x9c.fr wrote:
Dear list,
In a previous thread (that I cannot find again), I read that better
performances could be achieved via the "invokedynamic" instruction
rather than by using "MethodHandle" instances.
However, it is not clear to me whether this is true only for the
current state of the implementation, or should remain true in the
future (read "at the time of JDK7 release").
It's true for all implementations if the target of invokedynamic is stable
(don't change too often).
Thanks for the information; is there a reasonable estimate of the different
speeds (supposing that the target would indeed be constant). I mean, is
the gap as huge as between reflection and handles?
No, the gap is not as huge. Theorically, if the method handle is stored
in a static final field, the difference is just a pointer check.
If useful, here is a summary about the context: implementation
of both an interpreter and a compiler supporting closures.
There are 2 different use cases, one is how to implement a
function/method call,
in that case you should use invokedynamic. The other is how to implement
a closure call,
in that case you should use MethodHandle.invoke{Exact|Generic}.
It's a little bit more complex if a callsite can call a closure or a
method like by example
the method 'call' in Groovy. In that case, you can use an invokedynamic
and if the first parameter
is a MethodHandle and use the MHs.genericInvoker (or MHs.exactInvoker)
as target MethodHande.
Anyway, as you see you should choose to use one mechanism or the other
depending
on the use case and not on some benchmark.
Well, I do not fully understand your point. To some extend, it appears to me
that both mechanisms can be used to achieve the very same effect. That's
why I thought the "director's cut" should be performances.
if you know the method handle at link time, you should use invokedynamic,
if you don't know you should use MH.invokeExact.
Please note that for interoperability reasons, it will not be possible
to use built-in currification-like support provided by handles.
Hence, all calls will be "total".M
Thanks in advance for any insight.
In you case, you can:
- use MethodHandle instead of j.l.r.Method when doing native call.
This is actually what is done in (unreleased) code.
This resulted in a huge speed-up, but was wondering if I should use
"invokedynamic" instead.
- use invokedynamic in the bytecode generated by Cafesterol and
implement the corresponding bootstrap methods in Cadmium.
AbstractNativeRunner.closures should be a list of method handles.
- change the implementation of Value or Block to store a MethodHandle
in it and use it as a closure instead of using the Closure object.
Well, this too has been rewritten, there is no more a list of closures but
Value/Block is now a hierarchy of specialized classes (e. g. double,
bare block, closure).
From performance point of view is better to have unrelated final classes
instead of a hierarchy. double, closure etc. can be represented as
Double, MethodHandle (or a class that wraps MethodHandle) etc
and use Object as common super type.
There again, I wonder if the best is to do a
"Method.invokeExact(-)" or to play with the "invokedynamic" instruction.
The former has been implemented easily and is indeed quite fast.
Is it a good investment to move to le latter, given that it will
probably entail compile-time generation of one class per target in
my case ?
Having one class per target is not a requirement at all.
invokedynamic is just a way to install a method handle at a callsite.
Let's take examples (sorry my Caml is a little rusty):
# let rec fib n =
if n< 1 then 1 else fib(n-1) + fib(n-2);;
here fib(n-1) and fib(n-2) should be encoded using invokedynamic.
# p#get_x;;
p#get_x is also an invokedynamic.
# let f = (function x -> 1);;
here f should be a MethodHandle so
# f 1;;
is a call to MethodHandle.invokeExact()
Thanks for the thorough information.
Kind regards,
Xavier Clerc
Rémi
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
