[jruby] JRuby+Truffle Update

Chris Seaton chris at chrisseaton.com
Thu Dec 31 19:43:05 JST 2015

Hello all in the JRuby community,

It has been a long time since there was any centralised update from the
JRuby+Truffle research project, so the end of 2015 provides a good
to do that.

If you aren’t already aware of it, JRuby+Truffle [1] is a research project
provide a new high performance and complete backend for JRuby, using two new
pieces of technology from Oracle Labs - the Truffle language implementation
framework and the Graal JIT compiler.

There were two goals there - high performance, meaning it's fast, and
meaning that it runs real Ruby code. Let’s review how JRuby+Truffle is
doing on
those two fronts.

As a very crude overview of performance, JRuby+Truffle with the latest
development version of GraalVM across 63 benchmarks is over 31x faster than
2.3.0, over 32x faster than Rubinius 2.5.8, over 17x faster than Topaz (Ruby
using PyPy technology) and over 24x faster than JRuby with


Some benchmarks, such as the ‘linear dodge’ composition filter from PSD.rb
over 300x faster than JRuby - and this is real code taken from real gems
allocate objects and use metaprogramming - not artificial scientific
If you just focus on the ’shootout’ benchmarks we’re almost 6x faster than
JRuby, but if you focus on production benchmarks from Chunky PNG and PSD.rb
we’re over 50x faster than JRuby. We think this shows how can be optimise
effectively on more realistic Ruby code than synthetic benchmarks.

Obviously, benchmarking is extremely complex, results vary enormously and
should read more and examine them for yourself if you are interested. An
chapter of my PhD is devoted to the how and why of our benchmarking system
and the same approach is now in use by IBM’s OMR project [4], and Oracle’s
of time compilation project for Java [5].

In terms of completeness, JRuby+Truffle passes 93% of the RubySpace language
specs [6] and 90% of the core library specs [7]. We also pass a great deal
the stdlib specs, but coverage is very patchy there so talking about the
percentage doesn’t make sense [8]. Most importantly, we are starting to be
to run real parts of the Ruby ecosystem. In 2015 we became able to run web
servers like Webrick, web frameworks like Sinatra and database clients like
Redis working.

I would very cautiously say that if you take a gem or application that
use native code and doesn’t use some tricky things from the standard library
like openssl, and keeping in mind those same restrictions across all your
dependencies, then it will probably more or less work on JRuby+Truffle.
now ready to start accepting GitHub issues if this isn’t the case.

Looking forward, we aim to show that running Rails on JRuby+Truffle is
in 2016. That doesn’t mean running any random Rails application, but it does
mean showing that the stack in general works on JRuby+Truffle. As a first
JRuby+Truffle already passes 99% of Active Support specs. Is JRuby+Truffle
to be any faster at running Rails, when it eventually can do that? Well,
quietly confident based on what we know Rails applications do, and what we
JRuby+Truffle optimises well. Metaprogramming [9, 10], small intermediate
structures [11] and lots of method calls are what JRuby+Truffle does best
and it’s also what Rails does [3].

JRuby+Truffle is now a regular part of the JRuby 9 releases. You still need
modified JVM to run it - I recommend the GraalVM, available from the Oracle
Technology Network [13], or you can build Graal from scratch from OpenJDK
if you
want [14]. It should soon be possible to use Graal in unmodified JDK 9 early
access builds, so you won’t even need a custom JVM any more.

GraalVM is actually even more than a VM with the Graal JIT compiler in it.
Oracle Labs are working on many Truffle languages, such as R [15] and
JavaScript. The GraalVM integrates all these languages into one package and
beginning to provide sophisticated interoperability between them.

The summary is that JRuby+Truffle is making fast progress. We are very
close to
having a complete implementation of the language and most of the standard
library. Performance has never permanently regressed from our early
in 2013 as we’ve implemented more and more of the language - in fact
has only increased.

The team is now three Oracle employees: me (Chris), Kevin, Petr, and our JKU
Linz collaborator, PhD student Benoit. Of course, there’s a large team
behind us
working on Truffle and Graal, and we also have open source contributors
such as
Brandon Fish.

We're preparing to grow the team, so if this work interests you and you are
looking for a job please get in touch with me by email. We're looking for
with a good understanding of Ruby, Rails and Java. You don’t need to be an
expert on compilers (but it’s great if you are). Remote work is fine.

As always, we want to make it clear that we’re building on the efforts of
JRuby, core Ruby and Rubinius teams and are very grateful for all their


[1] https://github.com/jruby/jruby/wiki/Truffle
[2] http://jruby.org/bench9000/
[3] http://chrisseaton.com/phd/
[4] https://www.youtube.com/watch?v=kOnyJurioyw
[5] https://www.youtube.com/watch?v=Xybzyv8qbOc
[6] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-language-report/html/
[7] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-core-report/html/
[8] http://lafo.ssw.uni-linz.ac.at/graalvm/jruby/specs-library-report/html/
[10] https://www.youtube.com/watch?v=lRMWwjqbXUo
[11] http://chrisseaton.com/rubytruffle/small-data-structures/
[13] https://github.com/jruby/jruby/wiki/Downloading-GraalVM
[14] https://github.com/jruby/jruby/wiki/Building-Graal
[15] https://bitbucket.org/allr/fastr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ruby-lang.org/pipermail/jruby/attachments/20151231/46b142e5/attachment.html>

More information about the JRuby mailing list