Slides

One Compiler
July 2016

The stack of a running Java HotSpot VM has stack frames from multiple compilers (the C compiler, the client compiler, and the server compiler) as well as bytecode interpreter stack frames. That complicates essential VM tasks (stack walking, garbage collection, and deoptimization), increases maintenance costs, and makes porting to new hardware architectures difficult. We argue that a single compiler is sufficient: Using the Graal compiler in different configurations, we can execute Java, JavaScript, and many other languages. The stack only contains a single kind of stack frame: frames from ahead-of-time compiled code, interpreter frames (from an ahead-of-time compiled AST interpreter), frames just-in-time compiled code, and deoptimized frames (ahead-of-time compiled code with deoptimization entry points). In this talk, we outline the necessary components of such a streamlined system: deoptimization to compiled frames (in contrast to deoptimization to interpreter frames), access to low-level OS data structures directly from Java, and writing the whole runtime system (including the garbage collector) in Java.

Authors: Christian Wimmer

Venue: JVM Language Summit, August 1 - 3, Santa Clara, CA; http://openjdk.java.net/projects/mlvm/jvmlangsummit

Content:

Hardware and Software, Engineered to Work Together