Projects, which use JSR292

Charles Oliver Nutter headius at headius.com
Tue Feb 15 10:03:33 PST 2011


On Tue, Feb 15, 2011 at 8:50 AM, Kirill Shirokov
<kirill.shirokov at 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


More information about the mlvm-dev mailing list