Graal: Not Just a New JIT for the JVM

Tell me a bit more about the projects that you're working on.

I spend most of my time working on TruffleRuby and a small portion of my time working on project Loom. TruffleRuby is an attempt to produce a high-performance Ruby implementation using a language implementation framework called Truffle. We developed the idea of Truffle; you shouldn't have to write a complicated compiler for your language. You should be able to write a simple abstract syntax tree interpreter and we should be able to specialize that for the actual program that you're running so that rather than interpreting it we specialize so that it runs fast and it's a lot like compiler, but you as a language implementer don't have to write a complex compile yourself. This is based on what’s technically known as partial evaluation. It's an abstract interpreter that you can think of as running your program with all possible inputs at the same time, all small chunks of your product like a method, understanding what's constant in that and specializing based on it. That obviously doesn't work very well if you take methods in complete isolation but considering what method calls they make then you start to get something that can actually run very quickly.

What stage of development is TruffleRuby?

TruffleRuby is still classed as experimental and it will remain so at least for the rest of this year. We are making great strides towards being able to run more Ruby applications. We can now run some Rails applications and we've made some very big improvements in compatibility with C extensions written for the default Ruby implementation recently. But we're still in that process of scaling up to the size of application and testing more through gems. We’re starting to get details from potential customers and other users of what gems they're using in production so we can start adding them to our tests.

What are we talking about in terms of performance with TruffleRuby?

We can run a lot of code hundreds of times faster - once we've been able to warm up. Larger applications are going to be less pronounced because they're more likely to have I/O constraints, but we hope to be able to achieve good performance and also better compatibility than JRuby can offer right now with MRI. One of the Achilles heels that JRuby has is that he doesn't support the standard C extensions that MRI does. You can provide alternative Java extensions for it, some gems do that, but most of them end up being maintained by that JRuby core team. We’re going to support C extensions out of the box with very minimal changes. But also in some of the testing I've been doing where people have written C extensions you really don't need to. You can get just as good performance if not better from writing the pure Ruby version that you want to in the first place.

What's the focus of this talk? This talk isn't specifically about TruffleRuby, it's about Graal, right?

Yes. A lot of people will have heard about Graal as a new JIT. And it's important to understand what Graal can do for you, what Hotspot can't. We can do more with Graal than being a new JIT for the JVM. Graal is a compiler that is written in Java which makes it easier to work with and easier to experiment. So we hope going forward it can keep developing quickly compared to Hotspot which is notoriously hard to work with and become productive working with. But we can also apply Graal to places where Hotspot C2 cannot be applied. It's already used in experimental stuff in the JDK to do ahead of time compilation.

What's the goal for the talk?

I want to inform people what it's about. I want to tell them about the road that it will take of getting it to be a widely used JIT in the OpenJDK (It's currently available in OpenJDK if you enable various experimental options), and I want people to know the new possibilities it opens up.