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, it the gap as huge as between reflection and handles? >> 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. >> 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 a specialized classes (e. g. double, bare block, closure). 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 ? Thanks for the thorough information. Kind regards, Xavier Clerc _______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev