JRuby 1.1 released with major performance improvements

Nine months after JRuby 1.0 was released, and after 3 Release Candidates, the final JRuby 1.1 release is now available. InfoQ caught up with JRuby's Charles Nutter and Ola Bini to get details behind the changes in JRuby 1.1 and the future direction of the project.

Charles lists the big changes in JRuby 1.1:

The biggest improvements are:

• A full compiler, turning Ruby code into Java bytecode
• The IO subsystem has been rewritten to better match Ruby's behavior
• Our new Regexp engine supports Ruby's strings with greatly improved performance
• Overall performance is many times better than any of the 1.0 releases

We've also made hundreds upon hundreds of fixes for compatibility with Ruby 1.8.6. JRuby is by far the most compatible third-party implementation of Ruby available, and will be for a long time.

He continues with his view on performance in JRuby 1.1:

General Ruby code should almost all run a lot faster, especially if it uses regular expressions heavily. In general, we consider it a bug if a piece of Ruby code doesn't run faster in JRuby than in Ruby 1.8.6, so we're looking for bug reports to roust out any remaining bottlenecks.

Next to the JIT (Ruby source to Java bytecode Just In Time compiler), another reason for the performance improvements is the Joni, the Java port of the Oniguruma Regex engine. Ola gives an overview:

Basically, the regular expression engine is a complete port of Oniguruma, the Regex engine that Ruby 1.9 will use. Our port was done by Marcin Mielżyński, and seems to have better performance and also fixes several bugs that are still in the Oniguruma original.
The new implementation makes it possible for us to get better performance than any other Java based regex engine, while having extremely good compatibility with both Ruby 1.8 and Ruby 1.9. Most of the Re gexp and String methods have been totally redone to use the new engine effectively.

Charles adds some more details:

Because Ruby's strings are just byte collections, JRuby implements then using Java byte arrays. And because of this, none of the Java regular expression engines performed well for us; every regexp operation required converting byte[] to char[] and back. But Marcin Mielzynski, one of the JRuby committers, took on the effort of porting Oniguruma, a byte[]-based encoding-agnostic regular expression engine used heavily in Ruby 1.9. Because of his "Joni" library, we now have better regexp support than ever before, and basically all regexp performance issues have been resolved. It's a tremendous piece of work, and a great contribution.

As the development cycle for 1.1 ends, this - of course - means starting to think about future releases. One theme for the Ruby space is the support for the features in Ruby 1.9. Ola explains the current plans:

Right now [1.9] doesn't affect us that much, since it's still a development release. I see two ways it helps us: first, the 1.9 features are more stabilized, which means it will be easier for us to add them correctly to JRuby. And secondly, since we are starting to see the real performance gains of 1.9 we also have a good goal to compare against, now that we have surpassed 1.8 in basically every benchmark.

We have already started adding 1.9 stuff to JRuby, and we will continue doing that continuously. Of course, correctness and fixing takes precedence right now. but for example the Oniguruma port makes it easy for us to add the encoding support to strings and so on.

We haven't talked that much about 2.0. Personally, I see 2.0 as the release that will be totally 1.9 AND 1.8 compatible. For 1.2 we will work on Java integration and external API's. Our Java Integration features work really well right now, but there are a few holes in the implementation, and also some inefficiencies, so we're planning on doing a total overhaul of that subsystem. This is of course a major thing to do, but the gains will be quite nice too.

As always, performance is an important topic. Ola shows some areas that promise to yield perfomance improvements:

You will see performance improvements in basically every area, but the most improvements will be in areas where we can statically figure out that stack based local variables are safe, that eval isn't used, that nothing funky is going on. In those methods we can generally get large improvements from the compiler and if they are hotspots in your program this will improve general runtime substantially.

Charles offers his plans for the future:

After JRuby 1.1 the two big areas we want to look at are 1.9 support and better Java integration. That work may end up being JRuby 1.2 or it may be large enough that we go right to JRuby 2.0. And of course we'll continue improving performance to stay ahead of the pack...but right now we're pretty happy with it.
We're considering work on Ruby 1.9 features after JRuby 1.1 has been out for a while. However we're also hoping to see 1.9's feature set stabilize before we spend a lot of time in that area. We really don't want to chase 1.9 feature changes over the next year, especially since it seems that 1.9 is still evolving rapidly.

Charles also provides his ideas for further improving not just JRuby's performance, but the performance of all dynamic languages on the JVM:

I think we need to expose the amazing dynlang potential of the JVM at any cost. If that means creating a new, possibly incompatible "fork" of OpenJDK, so be it. There's no reason such work can't be integrated back into Java proper, and there's a truly incredible VM there waiting to be tapped. I think this is going to be a very big year for OpenJDK, now that people realize what they have access to. And you can be there will be JRuby work taking advantage of any OpenJDK experiments people come up with.

See more plans and projects to improve dynamic language support on the JVM  or directly take a peek at the Da Vinci Machine website for details on the research.

You can read up on InfoQ's coverage of JRuby.