New OpenJDK Project proposal: Project Metropolis
© Shutterstock / DeeaF
JVM architect John Rose has proposed the creation of a new OpenJDK Project to be titled “Project Metropolis”, an incubator for experimenting with advanced JVM implementation techniques. The next step will be a call for votes.
JVM architect John Rose is proposing a new OpenJDK Project to be titled “Project Metropolis.” According to the initial message (the discussion thread has been changed “so that the archives will be in better shape”), Project Metropolis is an incubator for experimenting with advanced JVM implementation techniques.
Project Metropolis overview: Java-on-Java
Rose explained that their goal is to re-implement significant parts of Hotspot’s C++ runtime in Java itself — a move they 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, they intend to 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.
Project Metropolis will be an experimental technology incubator, similar to the Lambda, Panama, Valhalla, and Amber projects. Rose explained that these 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.”
Advantages of implementing the Java runtime in the Java-on-Java style
- Self-optimization: They obtain more complete control of optimization techniques used for compiling the JVM itself.
- Self-determination: They 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).
- 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.
According to Rose, the key experiments for the Project Metropolis 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.
Metrics for startup, footprint, peak performance, and application latency will be developed and tracked — they will 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 help them to evaluate progress
toward their “eventual goals” of replacing, in the HotSpot reference implementation of Java, C++ code by Java code, and especially C2 by Graal.
If these experiments prove to be successful, they will be able to conduct additional experiments with the 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.
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. 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 will work together on this Project.
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).
The changes will be coordinated with the Graal development team [therefore adhering to practices set up by the Graal Project]. The goal of this move is to ensure that “changes from either project will not lead to regressions.” As a result, “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.”
Rose proposed Vladimir Kozlov, HotSpot JIT lead and a key AOT engineer as the Lead for Project Metropolis.
Thumbs up from Andrew Dinn of Red Hat
Andrew Dinn, Senior Principal Software Developer at RedHat welcomed Rose’s proposal. He added that “it is particularly valuable that a Java-on-Java implementation replaces the hard, black box that currently separates VM tech from JDK tech with a much more fluid, transparent boundary layer.”
However, he urged the community not to take his statement as representing an answer from Red Hat.
Rose later corrected the subject line in the message after Mark Reinhold reminded him that OpenJDK has no “RFC” actions. The subject line is now called Call for Discussion: New Project: Metropolis.
Any Contributor may propose the creation of a new Project.
Step 0: Discuss [optional]
It is recommended that any proposal for a new Project be discussed publicly before being proposed for a vote. Send an e-mail describing the motivation, goals, and initial Lead of the proposed Project to the general discussion list. Include any suggested initial Authors, Committers, and Reviewers, if known. (Reviewers are only relevant if the Project will require formal change review.) Describe existing bodies of code, if any, that will be used as the Project’s starting point. The proposing Contributor should be an active participant in any subsequent discussion and should refine the proposal as necessary in response to comments.
At least one Group Lead must declare that their Group is a sponsor of the proposed Project. (Unlike the interim guidelines which required Group Members to vote for sponsorship, a Group’s Lead has the authority to declare that the Group is a sponsor of the Project.)
Step 1: Propose
Send a combined motion for the creation of the Project and the appointment of its initial Lead to the announcement list. The e-mail should contain the Project name, description, initial Lead name and qualifications, sponsoring Groups, and suggested initial Authors, Committers, Reviewers, if any. The voting method is Lazy Consensus and only current OpenJDK Members are eligible to vote.
The Bylaws specify separate votes on the creation of a new Project, by the OpenJDK Members, and the appointment of its initial Lead, by the Group Leads of the sponsoring Groups. Any such Group Lead may, therefore, request that the two motions be voted upon independently, though this is not expected to be the common case.
Step 2: Vote
Eligible voters cast their vote by sending e-mail to the general discussion list. Replying to the proposal will achieve this automatically for those people whose mail programs honor the
Reply-To header. The first line of the message body should be in the following form:
<vote> is one of
abstain. A justification for the vote may be provided on subsequent lines, and is required in order for a
vetovote to be valid. Multiple votes are allowed but only the most recent vote will be counted. Votes must be cast in the open, on the general discussion list; votes sent as private replies will not be counted.
Step 3: Announce Results
Once all OpenJDK Members have voted or the deadline has passed, the proposing Contributor must send the results to the announcement list. If the announcements are of approval then they must also be sent to the registrar.
Step 4: Appoint
The registrar will send an e-mail questionnaire to the new Project Lead to collect information necessary to launch the Project on OpenJDK. In addition to information for web pages, file repositories, and mailing list(s), the Lead will be asked to select the initial Authors, Committers, and Reviewers (if necessary). The registrar will issue registration invitations as appropriate and will update the Census.