More than a year has passed since the initial release of the 1.6 series of JRuby, and now the first preview version of JRuby 1.7.0 has just been released.
JRuby 1.6 was the first version that was Ruby 1.9.2 compatible, and with JRuby 1.7, Ruby 1.9 has even become the default runtime mode. Other notable changes mentioned in the release notes are:
- Many 1.9.x compatibility fixes
- Support for Java 7’s invokedynamic
- Performance and concurrency improvements
- Java 5 support dropped (Java 6+ required)
- Update to Rubygems 1.8.24
- Update to Rake 0.9.2.2
Support for invokedynamic is automatically enabled, but to get the most out of it, you should run it on the most recent Java 7 build available. InfoQ had the chance to talk to Charles Nutter to learn more about how JRuby profits from invokedynamic support:
JRuby's use of invokedynamic brings us much closer to the goal of Ruby running at Java speeds. Because the JVM now understands exactly how we make dynamic calls, it can optimize them just like it does for normal statically-typed calls. Suddenly, all the tricks that make Java fast apply to plain old Ruby code. It's truly amazing.
There's a tremendous amount of untapped potential, both in JRuby and in the JVM. Current JRuby uses of invokedynamic are not all 100% optimal, and in some cases they have unnecessary overhead that keeps them artificially slow. Now that we've got invokedynamic wired up and stable we can focus on improving our use of it. The JVM (Hotspot, specifically) can also do a lot more for us than it does now. The initial Java 7 release did not optimize invokedynamic well, but it was functional. Update 2 brought solid JVM JIT support and optimizations to the server compiler. Update 6 should include a rewrite of the JIT logic that will make it easier for the full set of JVM optimizations to apply to invokedynamic calls.
We'll be working with the Hotspot folks to make sure invokedynamic continues to improve.
InfoQ: Is JRuby now definitively the fastest Ruby implementation around?
I think it's probably safe to say that, finally. There will always be cases that we don't handle well or which require future JVM improvements, but in general JRuby should almost always be faster than other implementations. And with ongoing invokedynamic work in JRuby and OpenJDK, we're going to pull away even more.
InfoQ: What about Fibers, I've heard rumors that Java 8 might get some support for coroutines. Do you know more about that?
Unfortunately the door is closed for something as major as coroutines to get into Java 8, but they're a possibility for Java 9. To help reduce the overhead of JRuby's Fiber implementation, we're working with a Google Summer of Code student to explore a Kilim-based implementation. We don't know if the effort will succeed, but he's making progress already.
InfoQ: Tom Enebo and you are moving from Engine Yard to Red Hat, but you'll continue to work on JRuby. Are you also going to work on Ceylon, Red Hat's own JVM language?
Anything's possible! I'm excited about the move because it will be part of my job description to explore other JVM languages and JVM support for them in addition to working on JRuby. I truly believe the JVM is the best runtime for languages, be they static or dynamic; now I'm going to prove it.
InfoQ: Thank you for the interview!
You can download the preview1 release from the JRuby website, or if you're using RVM, you can install it with rvm install jruby-1.7.0.preview1.
