Call for Discussion: New Project: Leyden

[mark.reinhold at oracle.com]

2020/4/27 13:05:06 -0700, volker.simonis at gmail.com:
> On Mon, Apr 27, 2020 at 6:40 mark.reinhold at oracle.com wrote:
>> ...
>> 
>> 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?

(I’m not sure what you mean by this.)

>                                                                 Which
> Java language/VM features are you ready to sacrifice for better
> startup and lower footprint?

Short, preliminary answer: Loading classes not known at build time, plus
arbitrary uses of method handles and the `invokedynamic` bytecode.  (Uses
of those features to, e.g., implement lambda expressions will work.)

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

I expect there to be some overlap, but it’s too early to say in detail.

>       And finally, how do you plan to prevent the fragmentation of the
> Java ecosystem into "full Java" and "static Java"?

Recall the first constraint: A static image runs just one application,
and no other.  A static image cannot run any code from outside the image,
so there’s no risk that any particular image will somehow effectively
define an alternate, non-standard version of the platform.

It is true that the set of applications that can run in “static Java”
will be a subset of those that require “full Java,” but then so is the
set of applications that can run with just the `java.base` module vs.
those that need more of the platform’s modules.

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

I don’t expect that we’ll have to make significant changes to HotSpot
in support of static images.  I’d be surprised if, e.g., the GCs will
require any change at all.  The HotSpot that you get in a static image
will, however, most likely be stripped down to omit features that are
of less interest in static images.  (I’m sure we’ll have a thorough
discussion of exactly what those features are at some point.)

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

This is absolutely not about “one Oracle product team fighting against
another one.”  The two teams will work together on this effort, hopefully
with additional contributions from non-Oracle developers.  I fully expect
regular participation from Christian Wimmer, Thomas Wuerthinger, Vojin
Jovanovic, and other members of the GraalVM team.

- Mark