RFC, Project Metropolis`

[John Rose]

<http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html>

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