3 ms·

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 J

by KMag 6y ago

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.

mukel 6y ago
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.
- aarchi 6y ago
  Pypy implements Futamura projections too.
- KMag 6y ago
  > 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.

by KMag 6y ago

mukel 6y ago

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.

aarchi 6y ago
Pypy implements Futamura projections too.
KMag 6y ago
> 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.