Hacker News Reader

Comment by vnorilo | Hacker News Reader

Truffle works by taking your interpreter and generating a compiler by partial evaluation [1]. So I believe they have written a JVM bytecode interpreter and Truffle makes the JIT.

I'm super impressed by how the Truffle/GraalVM team has been able to turn this theoretical concept into a system that yields production grade compilers (although this Java on Java is not there yet).

"A very important detail of this implementation is that it’s implemented in Java. Java on Truffle is Java on Java! Self-hosting is the holy grail of Java virtual machine research and development." - now if you chuckled and imagined this as xkcd, I'm with you. Regardless I think this is really not some ultimate geek olympics fantasy, but that truffle and graal will be equally if not more transformative to PL reseaech than LLVM has been.

1: http://blog.sigfpe.com/2009/05/three-projections-of-doctor-f...

View on HN

High-performance JITs via partial evaluation of interpreters is the impressive part.

Self-hosting Java isn't a huge deal. IBM's Jalapeno/JikesRVM has been a JVM implemented almost entirely in Java for decades. It self-compiles by using the highest tier of its JIT on itself and then dumps the native code in memory to disk as an executable. Though, as far as I know, JikesRVM doesn't keep around its own bytecode (or an SSA representation of itself) for later dynamically re-optimizing itself or inlining parts of the JVM in user code hot spots. Hopefully a Truffle/Graal-based production JVM would be able to dynamically re-optimize/inline almost all of the JVM into hot spots in user code.

Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step.

Currently Graal/Truffle implements the first Futamura projection: you give it an interpreter written in Java, it automatically generates a compiler (JIT). In this mode we have to keep the interpreter IR graphs (blueprints) around for partial evaluation.

With the first Futamura projection: Partial evaluator + interpreter + user code.

There's active work on implementing the second Futamura projection, where you partial evaluate the partial evaluator with respect to the interpreter, generating a specialized partial evaluator for that interpreter. With the second Futamura projection: (Specialized partial evaluator + interpreter) + user code.

This is truly fascinating and beautiful and the fact that it works for Java and not just a toy academic prototype is mind-blowing.

Pypy implements Futamura projections too.

> Java on Truffle is a normal Java application, it can run on a vanilla OpenJDK, doesn't need the bootstrap step.

Okay, but if you're not bootstrapping, then you still need to keep OpenJDK around, and you're still hugely dependent upon big chunks of C++ code in OpenJDK, particularly in the garbage collector, unless they've added a crazy in-memory bootstrapping hook to OpenJDK to switch garbage collectors without shutting down the JVM.

Maybe there are some rapid development advantages to not requiring bootstrapping, but that means huge amounts of complexity around allowing re-definition of classes at runtime, particularly key JVM internals. Changing a tire without stopping the car is going to be very tricky.

Reply on news.ycombinator.com