On Tue, Feb 15, 2011 at 8:50 AM, Kirill Shirokov
<kirill.shiro...@oracle.com> wrote:
> - JRuby by Charles Oliver Nutter
> - PHP.reboot by Remi Forax
> - Smalltalk implementation by Mark Roos (in progress)

My "other" language, Mirah, also has prototype support for
invokedynamic using JSR-292, in the following form (similar to C#):

def foo(obj:dynamic)
  obj.bar # dynamic call
end
> And the main question to early adopters: is JSR292 really helping you: 
> simplifies and clarifies your code, do you expect performance improvements 
> over the "old" code as soon as this will be addressed in HotSpot?

These are definitely the two benefits we're looking forward to. I'll
address them seperately:

* Code simplification

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

* Performance

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

- Charlie
_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Reply via email to