MethodHandle vs invodynamic (performance-wise)

[Rémi Forax]

On 02/13/2011 10:07 AM, forum at 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).

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

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

>
> Kind regards,
>
> Xavier Clerc
>
> PS: I am quite reluctant to conduct micro-benchmark, especially
> because JDK implementation is moving faster than my tests...

Rémi