(original) (raw)

Project Metropolis Proposal

From: John Rose
To: discuss@openjdk.java.net
Subject: Call for Discussion: New Project: Metropolis

I would like to invite discussion on a proposal for a new OpenJDK Project[1], to be titled “Project Metropolis”, an incubator for experimenting with advanced JVM implementation techniques. Specifically, we wish to re-implement significant parts of Hotspot’s C++ runtime in Java itself, a move we call Java-on-Java. The key experiments will center around investigating Graal[2] as a code generator for the JVM in two modes: as an online compiler replacing one or more of Hotspot’s existing JITs, and as an offline compiler for Java code intended to replace existing C++ code in Hotspot. In the latter role, we will experiment with static compilation techniques (such as the Substrate VM[3]) to compile Java into statically restricted formats that can easily integrate with C++ as used in Hotspot.

The Project will be an experimental technology incubator, similar to the Lambda, Panama, Valhalla, and Amber projects. Such incubator projects absorb changes from the current Java release, but do not directly push to Java releases. Instead, they accumulate prototype changes which are sometimes discarded and sometimes merged by hand (after appropriate review) into a Java release.

(In this model, prototype changes accumulate quickly, since they are not subject to the relatively stringent rules governing JDK change-sets. These rules involving review, bug tracking, regression tests, and pre-integration builds. The Metropolis project will have similar rules, of course, but they are likely to be more relaxed.)

Implementing the Java runtime in the Java-on-Java style has numerous advantages, including:

• Self-optimization: We obtain more complete control of optimization techniques used for compiling the JVM itself.
• Self-determination: We can decouple the JVM from changes (possibly destabilizing ones) in other implementation languages (C++NN).
• Simplification: More consistent usage of the “native” language of the Java ecosystem, reducing costs to contributors and maintainers.
• Speed: More agile delivery of new JVM backends (future hardware), new JVM frontends (value type bytecodes), new bytecode shapes (stream optimizations), and application formats (static application assembly).

However, the Java-on-Java tactic has significant risks which must be investigated and reduced before we can think about deploying products. These risks are:

• Startup: Startup overheads for Java code must not harm overall JVM startup.
• Isolation: GC or JIT activity required by Java-on-Java execution must not interfere with application execution.
• Density: Java-based data structures may require enhancement (such as value types) to support dense data structures competitive with C++.
• Succession: Adoption of Java-on-Java implementations must not cause regressions for customers who rely on the quality and performance of existing modules.

Therefore, the key experiments for the Project will include:

• Running Graal to statically compile Java code in a “native compilation mode” to prepare JVM components that can replace C++ components. (This will extend existing work with AOT and/or the Substrate VM.)
• Statically compiling Graal itself (again in a native compilation mode) to run as a JIT, evaluating it as a successor to C2.
• Isolating the resulting Java-on-Java component (i.e., Graal running as a JIT) from application code, especially with respect to GC dynamics, name resolution, and side effects.

The “native compilation mode” referred to above means that the compiler will produce a kind of object code that uses C-like calling conventions and a smaller runtime, rather than the specialized calling sequences and runtime required by JIT-generated Java code. Such object code is appropriate to separate compilation as a stand-alone program or component of a larger program like HotSpot, usually at the cost of high-end features like code instrumentation and dynamic reoptimization.

We will develop and track metrics for startup, footprint, peak performance, and application latency, to be used to characterize the effects (in startup, isolation, density, and quality) of implementing Java on Java. An iterative cycle of such metrics, community evaluation, and regression testing will enable us to evaluate progress toward our eventual goals of replacing, in the HotSpot reference implementation of Java, C++ code by Java code, and particularly C2 by Graal.

If these experiments are successful, numerous additional experiments are possible within the overall goal of implementing Java-on-Java:

• Using Graal as a replacement for the client JIT (C1).
• Using Graal to code-generate a bytecode interpreter.
• Using Graal to spin adapters, such as native-to-Java bindings.
• Using Graal to dynamically customize other JVM hot paths.
• Prototyping new JVM features, such as value types, in Graal.
• Coding native methods in statically-compiled Java.
• Coding metadata access and processing in Java.
• Coding smaller JVM modules in statically-compiled Java, such as class file parsing or verification.
• Coding GC logic in statically-compiled Java.

However, the Project will be a success even if it only lays the foundation for such additional use cases, to be investigated by future projects. It seems likely, today, that the key goal is creating a flexible code generation technology, in Java, for use by the JVM. Achieving this first goal is an important step toward many future upgrades to the Java technology stack.

The Project will be sponsored by the HotSpot Group. Project members will include HotSpot team members (including the JIT, GC, runtime, and performance teams), Graal project members from Oracle Labs, and non-Oracle developers from organizations interested in the Java-on-Java problem.

Relations to other projects:

• The project will start with a full copy of the JDK source base.
• The project will preserve relevance by tracking these sources.
• The project will contain the Graal repository, or a copy thereof.
• The project will not feed change sets directly into any JDK release.
• The project will routinely push changes to the Graal repository.

Changes to the Graal repository are likely to include:

• Support for static compilation (including AOT changes).
• Integration APIs with the JVM (beyond the current JVMCI).
• Optimizations specific to code running Java-on-Java patterns.
• General-purpose optimizations (to replace C2).
• New platform optimizations (such as AVX).
• Proposed new instructions (such as value types).

Such changes will coordinated with the Graal development team, adhering to practices set up by the Graal Project, in such as way that changes from either project will not lead to regressions. This means that each project will perform some amount of integration testing for both projects. Since the Graal project is an active project in its own right, coordination between the projects, and overlap between the teams, is a necessary condition for the success of the Java-on-Java experiments.

For documentation beyond Java APIs, and for design works in progress, the Project should be supplied with a wiki writable to all Project committers. Alternatively, the Graal or HotSpot wiki could be used.

Finally, I would like to propose Vladimir Kozlov (the HotSpot JIT lead and a key AOT engineer) as the Lead for the Project.

[1]: http://openjdk.java.net/projects/#new-project-vote
[2]: http://openjdk.java.net/projects/graal/
[3]: https://www.youtube.com/watch?v=3JphI1Z0MTk&feature=youtu.be&t=2m38s