Project Leyden: Beginnings

[Ioi Lam]

On 5/20/2022 9:16 AM, Volker Simonis wrote:
> Hi Mark,
>
> Thanks for your all your efforts to finally get Leyden started!
>
>> The ultimate goal of this Project, as stated in the Call for Discussion
>> [1], is to address the long-term pain points of Java’s slow startup
>> time, slow time to peak performance, and large footprint.
>>
> You're probably aware of the CRaC project [1] which as well addresses
> the first two of these pain points (slow startup & slow time to peak
> performance) by leveraging checkpointing (aka. snapshotting) and
> restoring (aka. resuming) of fully warmed up JVM instances.
>
> [1] https://openjdk.java.net/projects/crac/
>
>> In the Call for Discussion I proposed that we address these pain points
>> by introducing a concept of _static run-time images_ to the Java
>> Platform, and to the JDK.
>>
>>    - A static image is a standalone program, derived from an application
>>      and a JDK, which runs that application -- and no other.
>>
>>    - A static image is a _closed world_ with respect to the classes that
>>      it can load: At run time it cannot load classes from outside the
>>      image, nor can it create classes dynamically.
>>
>> The closed-world constraint imposes strict limits on Java’s natural
>> dynamism, particularly on the run-time reflection and class-loading
>> features upon which so many existing Java libraries and frameworks
>> depend.  Not all applications are well suited to this constraint, and
>> not all developers are willing to live with it.
>>
>> So rather than adopt the closed-world constraint at the start, I propose
>> that we instead pursue a gradual, incremental approach.
>>
> Now that the goal of exploring "static images" is not the main goal of
> Leyden anymore (you should probably update the Leyden project page [2]
> to reflect this), the goals of CRaC and Leyden seem to match even
> more. CRaC's  new execution model doesn't impose any constraints on
> "Java’s natural dynamism" so it should naturally support most
> server-side applications out of the box. Instead, CRaC imposes a new
> constraint for Java applications which we call "snapsafety".  A
> snapsafe application can operate correctly and securely after it has
> been restored from a previously checkpointed (and possibly cloned)
> state. The main challenge for CRaC is to first make the JVM and the
> core libraries snapsafe before it exposes hooks to libraries and
> application to give them a chance to become snapsafe as well.
>
> [2] https://openjdk.java.net/projects/leyden/
>
>> We will explore a spectrum of constraints, weaker than the closed-world
>> constraint, and discover what optimizations they enable.  The resulting
>> optimizations will almost certainly be weaker than those enabled by the
>> closed-world constraint.  Because the constraints are weaker, however,
>> the optimizations will likely be applicable to a broader range of
>> existing code -- thus they will be more useful to more developers.
>>
>> We will work incrementally along this spectrum of constraints, starting
>> small and simple so that we can develop a firm understanding of the
>> changes required to the Java Platform Specification.  Along the way we
>> will strive, of course, to preserve Java’s core values of readability,
>> compatibility, and generality.
>>
> It seems to me that "snapsafety" could be such a constraint and I hope
> for a fruitful and successful cooperation between the two projects.

I think we have an opportunity in Leyden to improve the language and 
platform to support such concepts. I don't know the details of 
"snapsafety", but in general we should have language support to indicate 
some sort of "immutable" constraints. These constraints can be validated 
(so that we can use pre-optimized snapshot (s)), or invalidated (so we 
will go back to the old slow-but-correct initialization).

Also, in addition to a single snapshot of an app, perhaps we can also 
consider multiple snapshots at a lower granularity.

One parallel to draw from is the "constexpr" keyword in C++. However, 
"constexpr" only deals with language-level constructs. For Java, perhaps 
we need something that includes a wider set of environmental 
dependencies. For example, many immutable tables in Java apps are 
created from external XML files. Do we want a way to snapshot such 
tables? Maybe we can do that if the XML files are statically stored 
inside a jlink image?

Again, I don't know what the answer is, but I am excited that we are 
able to look for solutions at all levels of the language and platform.


Thanks
- Ioi


>
> Thank you and best regards,
> Volker
>
>> We will lean heavily on existing components of the JDK including the
>> HotSpot JVM, the C2 compiler, application class-data sharing (CDS), and
>> the `jlink` linking tool.
>>
>> In the long run we will likely embrace the full closed-world constraint
>> in order to produce fully-static images.  Between now and then, however,
>> we will develop and deliver incremental improvements which developers
>> can use sooner rather than later.
>>
>> Let us begin!
>>
>> - Mark
>>
>>
>> [1] https://mail.openjdk.java.net/pipermail/discuss/2020-April/005429.html
>>
>> // https://openjdk.java.net/projects/leyden/notes/01-beginnings