Ikai L. wrote:
When the JRuby core developers asked everyone what we wanted most, for
some reason everyone screamed, “Performance!” Performance is nice, but I
would have liked more tight integration with Java. For instance, we
still haven’t figured out how a trivially easy way of doing MapReduce
(Would LOVE to hear how to do this if anyone has done it)
Here’s my #1 goal for JRuby 1.4 (or whatever the JRuby that results from
a summer of work is called):
- Reduce the gap between Java and Ruby.
This can be broken down into several subgoals:
- Better compiler that produces the most optimized, idiomatic code
possible given modern compiler techniques and the complexities of the
This means a move to a more modern compiler design, where we produce an
intermediate representation and then do several optimization passes over
it. Initially this would be static optimizations, like turning Fixnum
loops into int loops, eliminating closer dispatch for literal iterations
like [1,2,3].each and 5.times, and so on. Later, it could mean profiled
optimizations, like determining which call we’re always making and being
smarter about doing that call. This would help bring execution
performance parity with some of the newer Ruby impls.
- Gutting the internals of Java integration to reduce object churn,
weakref usage, call protocols, and coercion semantics.
This would be a moderately big job, but the payoff would be huge. JI is
expensive these days mostly because of all the object wrapping and
coercing we have to do, as well as a number of unoptimized paths. Fixing
that would improve JI perf uniformly and reduce the number of hops from
a Ruby call site to the actual Java code. We’d also probably have an
easier path to using invokedynamic for Java invocation and an easier
path to step 3 below.
- Begin moving away from IRubyObject toward Object call paths.
This is the long-talked-about “lightweights” support, which would allow
us to pass Java objects through Ruby without ever coercing them or
wrapping them. This is a very large job, but I think it can be bitten
off in pieces. The approach would be to work backward through JI and
allow Java objects to propagate further and further up that particular
part of the call path. As they propagate higher and higher before being
coerced or wrapped, more and more of the Object call logic will fall
- Begin formalizing what Ruby types are and what Java types are and how
the two can interact.
This is work on ruby2java, for example, where we’re making it easier to
represent a Ruby class as some kind of “real” Java class. Initially we
could do things like always generate a stub Java class for every Ruby
class, so that in memory profiles, etc, we’d actually see those class
names. As we move forward, it could improve toward lazily generating a
class when first constructed, instantiating signatures for all Java
methods that exist at that point. This gives us the potential for
core-class call performance for all those methods as well as
I want to do all this plus take some vacation time and hit two
conferences I may need help.
To unsubscribe from this list, please visit: