On Jul 29, 11:07 am, Russel Winder <[email protected]> wrote: > It is not entirely clear that invokedynamic is actually good for > languages like Groovy and Jython. All the development was done for > JRuby, and I believe it helps that language a lot. Much of the > muttering in the Groovy and Jython community seems to indicate that the > overheads of using invokedynamic are potentially worse than not using > it.
This is completely untrue. Invokedynamic was designed with the needs of many languages in mind...not just JRuby and not just dynamic languages. Rémi Forax, one of the JSR members, is aware of how Groovy does its dynamic dispatch and also built his own "PHP Reboot" to apply invokedynamic to that language. Ola Bini, also on the JSR, works on JRuby, Ioke, and Seph, and helped ensure invokedynamic works properly for the needs of those languages. John Rose has done prototypes of JavaScript and Scheme on invokedynamic. Other active members on the MLVM list have seen great success applying invokedynamic to Smalltalk implementations. There is an intern who has been applying invokedynamic to Jython. I have mostly used JRuby for testing invokedynamic, but my statically-typed language Mirah uses it for dynamic dispatch very similar to Groovy's. And Attila Szegedi, a past contributor to Rhino has built a dynamic linking toolkit for invokedynamic called "dynalink", which Mirah already uses for its dynamic dispatches to Java classes and which JRuby will soon likely use for all invokedynamic-based calls. Invokedynamic was definitely not developed "for JRuby". Yes, I was one of the first to adopt the APIs and one of the most active consumers of it. I have done a lot of benchmarking to help the Hotspot folks make the initial release run fast, but there's more work to be done in update releases. That may mean that the most optimized cases are the ones which I've reported from testing JRuby...because I put in the work to report them. It does not mean in any way that invokedynamic was developed for JRuby or with only JRuby's use cases in mind. I also was not an active member of the JSR, and only offered external suggestions on small API improvements. I did suggest the current package name, java.lang.invoke, but I don't think that qualifies as something being "done for JRuby." Invokedynamic was designed by folks with many languages in mind. I suggest you read through and play with the API. MethodHandles provide a very general, generic way to manipulate arguments, call methods, handle exceptions, and convert types through a given call path, and for a growing number of cases it easily outperforms JRuby's inline caching. Groovy uses a similar mechanism to JRuby to optimize dynamic dispatch, and I would be very surprised if it could not be adapted to use invokedynamic directly. The invokedynamic bytecode provides a way to patch that chain of handles and a target method all the way back to the calling body of code, with Hotspot optimizing the whole shebang as if it were an invokevirtual or invokeinterface rather than a dynamic call. Even if you only use MethodHandles to replace java.lang.reflect.Method in dispatch, it provides a big boost; JRuby's Ruby-to-Java dispatches, which should be implemented very much like Groovy's, are often 2-3x faster with invokedynamic than they were before. - Charlie -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
