RFC, Project Metropolis`

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC, Project Metropolis`

John Rose-3
<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
Reply | Threaded
Open this post in threaded view
|

Re: RFC, Project Metropolis`

Andrew Dinn
Hi John,

On 14/09/17 06:08, John Rose wrote:
> <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.
Please don't take the the following as representing an answer from Red
Hat. With that qualification out of the way, I can say that am
personally very interested in contributing to a Java-on-Java OpenJDK
runtime -- having experienced many of the benefits of such a model
working on the JikesRVM and Xerox Interlisp-D runtimes.

This idea has many benefits, as you mentioned. I think 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. The more that those who use
the JVM can understand about what it does for them and at what cost the
better.

So, this gets a very excited thumbs up from me!

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
Reply | Threaded
Open this post in threaded view
|

Call for Discussion: New Project: Metropolis

John Rose-3
In reply to this post by John Rose-3
On Sep 13, 2017, at 10:08 PM, John Rose <[hidden email]> wrote:
>
> <http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html>


Here's a small bit of administration, for the record.

Mark has reminded me that OpenJDK has no "RFC" actions.

The official subject line for this discussion thread should be
"Call for Discussion: New Project: Metropolis", as documented here.
  http://openjdk.java.net/projects/#new-project-discuss

At the risk of splitting the thread, I am correcting the subject
line in this message, so that the archives will be in better shape.

My thanks to the responders so far, including Andrew Dinn:
  http://mail.openjdk.java.net/pipermail/discuss/2017-September/004341.html

The next step is a call for votes; please stay tuned for that.

— John
Reply | Threaded
Open this post in threaded view
|

Re: Call for Discussion: New Project: Metropolis

Christian Thalinger-4

> On Sep 18, 2017, at 12:40 PM, John Rose <[hidden email]> wrote:
>
> On Sep 13, 2017, at 10:08 PM, John Rose <[hidden email]> wrote:
>>
>> <http://cr.openjdk.java.net/~jrose/metropolis/Metropolis-Proposal.html>
>
>
> Here's a small bit of administration, for the record.
>
> Mark has reminded me that OpenJDK has no "RFC" actions.
>
> The official subject line for this discussion thread should be
> "Call for Discussion: New Project: Metropolis", as documented here.
>  http://openjdk.java.net/projects/#new-project-discuss
>
> At the risk of splitting the thread, I am correcting the subject
> line in this message, so that the archives will be in better shape.

Replying here then…

You and I are talking about this for quite a while now and I welcome this becoming an official OpenJDK project now.

How do you envision people working on this project?  Should individual people just become contributors and then work on whichever module they want to replace?

>
> My thanks to the responders so far, including Andrew Dinn:
>  http://mail.openjdk.java.net/pipermail/discuss/2017-September/004341.html
>
> The next step is a call for votes; please stay tuned for that.
>
> — John

Reply | Threaded
Open this post in threaded view
|

Re: Call for Discussion: New Project: Metropolis

John Rose-3
On Sep 21, 2017, at 4:26 PM, Christian Thalinger <[hidden email]> wrote:
>
> Replying here then…
>
> You and I are talking about this for quite a while now and I
> welcome this becoming an official OpenJDK project now.

Yes, we have.  We have been watching Java-based JITs slowly mature
since Jikes, Maxine, JavaC1, C1X, and now Graal.  The stars have
aligned, I think, for a major shift.

(In more detail:  I have enjoyed watching the experimentation in JVM
implementation techniques by Hanspeter Mössenböck's students at JKU,
with collaboration by Sun/Oracle Labs engineers.  There is a wealth
of literature just from that department, and Graal was grown there.
A good place to connect into this history is Titzer et al in VEE'10.
People get inspired in crazy ways; I just noticed a paper on doing
JVMs in Haskell and FORTH:
  http://wien.tomnetworks.com/uni/thesis_matevm_oneside.pdf )

(Ever further back:  Some of my happiest programming memories come
from hacking around in the Symbolics Lisp Machine OS, which was
extravagantly metacircular.  Anything not written in Lisp was written
in microcode and/or assembly code, in Lisp syntax, on a Lisp toolchain.
There was a flexible, hackable system.  Such flexibility never goes out
of style, I think, although there are always balancing concerns like
reliability and usability.)

> How do you envision people working on this project?  Should individual
> people just become contributors and then work on whichever module the
> want to replace?

This is not mainly up to me, but rather the guys you know:  Vladimir,
Igor, Thomas, Doug, Tom.  Whatever the group decides as a consensus
is where it will go.  Can we hope that you will be in the group???

That said, here are a few of my thoughts:

I notice that we are growing some tools and experience with branches
as a way to maintain multiple parallel experiments.  See Project Amber.
Maurizio's scripts keep the branches properly stacked into dependency
order and refreshed from their dependencies, and all of them from the
default branch.

If someone wanted to replace a relatively small, isolated component
like MethodLiveness, that would fit easily in a branch.

Trying to code up a simpler verifier in Java would be a worthy goal.
By simpler I don't mean a different algorithm, but rather a higher-level
expression of the same algorithm, more amenable to review and
validation, both human and robotic.

Anything is fair game:  The reflection runtime, the LinkResolver and
SystemDictionary, eventually the metadata itself (when we have more
control over object layout).  An especially tantalizing area would be
to find "hot spots" in the C++ code where JVM-specific optimizations
would improve the system performance more than a C++ optimizer
could do.  If we have a clever code shape we need generated for
the JVM, we can train Graal to do it for us, if we can figure out how
to replace the affected range of C++ code with Java code.  GC inner
loops are probably amenable to GC-specific optimization techniques.

The main driving function, I expect, will be making Graal compile itself
into a static-linked "C++ mode" (using SVM I hope), into a linkable Graal
JIT to supplant C2.  But that's just a driving function, not the endpoint,
of Java-on-Java.  An ambitious person could try to replace C1 or the
interpreter with Graal.

Did I mention this is likely to be a very long-running project?  :-)

— John
Reply | Threaded
Open this post in threaded view
|

Re: Call for Discussion: New Project: Metropolis

Christian Thalinger-4

> On Sep 21, 2017, at 3:31 PM, John Rose <[hidden email]> wrote:
>
> On Sep 21, 2017, at 4:26 PM, Christian Thalinger <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Replying here then…
>>
>> You and I are talking about this for quite a while now and I
>> welcome this becoming an official OpenJDK project now.
>
> Yes, we have.  We have been watching Java-based JITs slowly mature
> since Jikes, Maxine, JavaC1, C1X, and now Graal.  The stars have
> aligned, I think, for a major shift.
>
> (In more detail:  I have enjoyed watching the experimentation in JVM
> implementation techniques by Hanspeter Mössenböck's students at JKU,
> with collaboration by Sun/Oracle Labs engineers.  There is a wealth
> of literature just from that department, and Graal was grown there.
> A good place to connect into this history is Titzer et al in VEE'10.
> People get inspired in crazy ways; I just noticed a paper on doing
> JVMs in Haskell and FORTH:
>   http://wien.tomnetworks.com/uni/thesis_matevm_oneside.pdf <http://wien.tomnetworks.com/uni/thesis_matevm_oneside.pdf> )
>
> (Ever further back:  Some of my happiest programming memories come
> from hacking around in the Symbolics Lisp Machine OS, which was
> extravagantly metacircular.  Anything not written in Lisp was written
> in microcode and/or assembly code, in Lisp syntax, on a Lisp toolchain.
> There was a flexible, hackable system.  Such flexibility never goes out
> of style, I think, although there are always balancing concerns like
> reliability and usability.)
>
>> How do you envision people working on this project?  Should individual
>> people just become contributors and then work on whichever module the
>> want to replace?
>
> This is not mainly up to me, but rather the guys you know:  Vladimir,
> Igor, Thomas, Doug, Tom.  Whatever the group decides as a consensus
> is where it will go.  Can we hope that you will be in the group???

I certainly would like to but it all depends if this is in any way helpful to my current employer.

>
> That said, here are a few of my thoughts:
>
> I notice that we are growing some tools and experience with branches
> as a way to maintain multiple parallel experiments.  See Project Amber.
> Maurizio's scripts keep the branches properly stacked into dependency
> order and refreshed from their dependencies, and all of them from the
> default branch.
>
> If someone wanted to replace a relatively small, isolated component
> like MethodLiveness, that would fit easily in a branch.
>
> Trying to code up a simpler verifier in Java would be a worthy goal.
> By simpler I don't mean a different algorithm, but rather a higher-level
> expression of the same algorithm, more amenable to review and
> validation, both human and robotic.

I know that this would be your preferred first task.

>
> Anything is fair game:  The reflection runtime, the LinkResolver and
> SystemDictionary, eventually the metadata itself (when we have more
> control over object layout).  An especially tantalizing area would be
> to find "hot spots" in the C++ code where JVM-specific optimizations
> would improve the system performance more than a C++ optimizer
> could do.  If we have a clever code shape we need generated for
> the JVM, we can train Graal to do it for us, if we can figure out how
> to replace the affected range of C++ code with Java code.  GC inner
> loops are probably amenable to GC-specific optimization techniques.
>
> The main driving function, I expect, will be making Graal compile itself
> into a static-linked "C++ mode" (using SVM I hope), into a linkable Graal
> JIT to supplant C2.  But that's just a driving function, not the endpoint,
> of Java-on-Java.  An ambitious person could try to replace C1 or the
> interpreter with Graal.

Totally.  One thing I would like to see coming out of this project is a slimmed-down, less complicated version of HotSpot.  Remove C1, C2, CI and replace with Graal.  Same for the interpreter, as you say.

Since we have control over how Graal compiles code generating the interpreter from a DSL-type description as we did in "Superinstructions and replication in the Cacao JVM interpreter” should be easily doable (sorry, the old link to the paper is dead).  That would get rid of most (all?) handwritten interpreter assembly code while keeping or even improving current performance.

>
> Did I mention this is likely to be a very long-running project?  :-)

You didn’t have to :-)