Call for Discussion: New Project: Leyden

[Volker Simonis]

On Mon, Apr 27, 2020 at 6:40 PM <mark.reinhold at oracle.com> wrote:
>
> 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.
>

Definitely interesting and highly welcome!
Hope I'll find some time to contribute :)

>   - 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.

I think "adding static images" to the Java Platform Specification will
be the real tough part of this JEP. What are you envisioning here?
Something like the "compact profiles" [1] on Language/VM level? Which
Java language/VM features are you ready to sacrifice for better
startup and lower footprint? GraalVM has its "small and well-guarded
secret" :) called "LIMITATIONS.md". Is this the set of limitations
you'd expect for the Java Platform Specification of static images as
well? And finally, how do you plan to prevent the fragmentation of the
Java ecosystem into "full Java" and "static Java"?

[1] https://docs.oracle.com/javase/8/docs/technotes/guides/compactprofiles/compactprofiles.html
[2] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md

> 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].
>

While I personally like this approach and would very much welcome it
if it succeeds, I also think we have to be realistic. What makes you
believe that one JVM "can rule them all"?

HotSpot's current runtime system and GCs are quite sophisticated and
complex. Adding one more use case (i.e. "native image") which they'll
have to support, will further increase the code complexity and long
term maintenance costs. Have you evaluated these costs compared to a
complete new implantation or an implementation which leverages the
extensive work done in the GrallVM project?

I'm sincerely hoping that project "Leyden" is more than just an
instrument of one Oracle product team fighting against another one and
wish that the OpenJDK and the GraalVM teams could join forces for the
advance and benefit of the Java platform as a whole.

> 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] https://en.wikipedia.org/wiki/GNU_Compiler_for_Java
> [2] https://www.graalvm.org/docs/reference-manual/native-image/
> [3] https://openjdk.java.net/jeps/295
> [4] https://openjdk.java.net/jeps/310
> [5] https://openjdk.java.net/jeps/282