You are viewing content from a past/completed QCon

Presentation: Graal: Not Just a New JIT for the JVM

Track: Evolving Java & the JVM

Location: Whittle, 3rd flr.

Duration: 4:10pm - 5:00pm

Day of week: Monday

Slides: Download Slides

Share this on:

This presentation is now available to view on

Watch video with transcript

What You’ll Learn

  1. Find out what Graal is.
  2. Hear about its compilation approach, the differences between Hotspot C2 and Graal.
  3. Learn about its performance and plans for the future.


Graal is a new JIT compiler for the JVM and a possible replacement for Hotspot's C2. However, this isn't the whole story and the design of Graal enables it to do more than to be a great JIT. In this talk we'll take a look at the differences between C2 and Graal, what this can mean for the performance of your code, and what else is possible with this new JIT.


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.

But we can take that further. We have a thing called the Substrate VM, and allows you to compile applications down to a self-contained executable that has just enough of the VM to run when you need, and doesn't have the startup cost you would normally have associated with it, doesn't have a lot of extra baggage. That does require some things. At the moment we don't have a way to load new classes into that Substrate VM. So you have to compile something down that is a set application that's never going to need to load another Java class. if you can do that you can get something that can work standalone or can be compiled as a shared library to be embedded in another application.


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.

Speaker: Duncan MacGregor

Working on TruffleRuby and Project Loom with Graal

Duncan has a degree in Computer Science from Cambridge University and has worked on language implementation for several years including porting GE's Smallworld GIS system to work on the Java virtual machine.

He currently works for Oracle Labs on the TruffleRuby project.

Find Duncan MacGregor at

Last Year's Tracks