None of the JSR292 parts is in Groovy now, but we intend to make heavy use of it if the JVM allows it. What we target with this is for example that we no longer have to generate call sites at runtime. This is stress on permgen and not every garbage collector behaves as it should in my eyes. Another part that promises to be useful is ClassValue. We would in fact need a InstanceValue, but it will help already avoiding some big internal structures, that tend to cause problems. As for performance... I think it can help here if the inlining really works. In the end it very much depends on finding good guards here, which is part of the process for Groovy 1.8, even though Groovy 1.8 will not yet make use of JSR292. Since 1.8.0 will be release soon Groovy 1.9 will most probably make use of JSR292.
Jochen "blackdrag" Theodorou, Groovy in a post on the mlvm-dev mailing list.
As an implementer, the first benefit of JSR 292 is to greatly simplify the implementation of several common patterns:
- invokedynamic+CallSite.setTarget() allows to easily implement any kind of inlining caches (one element cache or bymorphic cache, tree of decision, etc.) which are the mothers of all optimizations of any dynamic languages.
- MutableCallSite.syncAll() allows to do thread safe deoptimization which is the root of all optimistic optimizations. No guard anymore ! (in reality, less guards).
- MethodHandle give you lambda for free.
- Predefined method handles avoid code generation for doing the plumbing required by features like varargs, spreads, named parameters. i.e adaptation between the calling and the target method.
- MethodHandles.asInstance() avoid code generation when bridging Java core interfaces like Comparator, Runnable, Callable and MethodHandle.
- invokedynamic bootstrap method ease the implementation of lazy intialization.
- ClassValue ease the storage of Class metadata.
- invokedynamic bootstrap method constants ease the storage of callsite metadata.
The second benefit is performance. Some performance improvement are already visible by example using metod handle for doing reflection is more efficient than using java.lang.reflect
especially when you deal with primitive types. Some improvement are yet to appear like inlining of the whole callsite target tree. Some will come later just because they require more works :)
About performance of the dynamic language runtimes, because JSR 292 simplifies the implementation of the runtime, I expect that existing runtime will introduce more optimizations just because the code is now simpler. PHP.reboot is all about that.
Rémi Forax, PHP.reboot in a post on the mlvm-dev mailing list.
Because we can use handles and invokedynamic, almost all of JRuby's call protocol will be drastically simpler than it is presently. JRuby has done a good job of re-inventing the wheel when it comes to dynamically optimizing Ruby method calls, but that optimization comes at the cost of great complexity: lots of generated handles of our own, complicated and difficult-to-inline call paths, and so on. Moving to indy will mean we can mostly delete all that logic (and I'm considering a Java 7-specific distribution artifact that does exactly that).
Because JRuby does a pretty good job optimizing, indy only recently started to be faster than our normal call protocol logic. I expect to see it get better and better as more of the method handle chain inlines and optimizes with the rest of the calling method. Seeing a recent indy build run 30% faster than our normal protocol was a great feeling.
Schedule-wise, JRuby was the first language to support JSR-292 in any form...about two years ago. We have not worked heavily on 292 support since then, but I intend to make JRuby 1.7 fully indy-fied from end to end (I estimate we'd release that some time this summer).
Charles Oliver Nutter, JRuby in a post on the mlvm-dev mailing list.