Call for Discussion: New Project: Leyden

mark.reinhold at oracle.com mark.reinhold at oracle.com

• Previous message: Type-parameterized complement to Object.equals(Object)
• Next message: Call for Discussion: New Project: Leyden
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I hereby invite discussion of a new Project, Leyden, whose primary goal
will be to address the long-term pain points of Java’s slow startup time,
slow time to peak performance, and large footprint.

Leyden will address these pain points by introducing a concept of _static
images_ to the Java Platform, and to the JDK.

  - A static image is a standalone program, derived from an application,
    which runs that application -- and no other.

  - A static image is a closed world: It cannot load classes from outside
    the image, nor can it spin new bytecodes at run time.

These two constraints enable build-time analyses that can remove unused
classes and identify class initializers which can be run at build time,
thereby reducing both the size of the image and its startup time.  These
constraints also enable aggressive ahead-of-time compilation, thereby
reducing the image’s time to peak performance.

Static images are not for everyone, due to the closed-world constraint,
nor are they for every type of application.  They often require manual
configuration in order to achieve the best results.  We do, however,
expect the results to be worthwhile in important deployment scenarios
such as small embedded devices and the cloud.

Project Leyden will take inspiration from past efforts to explore this
space, including the GNU Compiler for Java [1] and the Native Image
feature of GraalVM [2].  Leyden will add static images to the Java
Platform Specification, and we expect that GraalVM will evolve to
implement that Specification.  Developers who use only the standard,
specified static-image feature will then be able to switch with ease
between Leyden (in the JDK), Native Image (in GraalVM), and whatever
other conforming implementations may arise, choosing amongst tradeoffs
of compile time, startup time, and image size.

We do not intend to implement Leyden by merging the Native Image code
from GraalVM into the JDK.  Leyden will, rather, be based upon existing
components in the JDK such as the HotSpot JVM, the `jaotc` ahead-of-time
compiler [3], application class-data sharing [4], and the `jlink` linking
tool [5].

I propose to lead this Project with an initial set of Reviewers that
includes, but is not limited to, Alex Buckley, Bob Vandette, Claes
Redestad, Igor Veresov, Ioi Lam, Mandy Chung, and Vladimir Kozlov.

This Project will start with a clone of the current JDK main-line
release, JDK 15, and track main-line releases going forward.  We expect
to deliver Leyden over time, in a series of JEPs that will likely span
multiple feature releases.

Comments?

- Mark


[1] <a href="https://en.wikipedia.org/wiki/GNU_Compiler_for_Java">https://en.wikipedia.org/wiki/GNU_Compiler_for_Java</a>
[2] <a href="https://www.graalvm.org/docs/reference-manual/native-image/">https://www.graalvm.org/docs/reference-manual/native-image/</a>
[3] <a href="https://openjdk.java.net/jeps/295">https://openjdk.java.net/jeps/295</a>
[4] <a href="https://openjdk.java.net/jeps/310">https://openjdk.java.net/jeps/310</a>
[5] <a href="https://openjdk.java.net/jeps/282">https://openjdk.java.net/jeps/282</a>

• Previous message: Type-parameterized complement to Object.equals(Object)
• Next message: Call for Discussion: New Project: Leyden
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]