From: John Rose To: email@example.com Subject: Call for Discussion: New Project: Metropolis
I would like to invite discussion on a proposal for a new OpenJDK Project, 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 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) 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:
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:
Therefore, the key experiments for the Project will include:
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:
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:
Changes to the Graal repository are likely to include:
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.