Draft JEP 8315737: AOT Linked Classes

[Volker Simonis]

Hi Jon,

Thanks for the update and great to see this moving forward.

After reading the full JEP it became evident that  "Cached Data
Storage" is actually an extension of the existing and well known
"Class Data Sharing" feature. However, the current description
introduces "CDS" (which is the well known acronym for "Class Data
Sharing" since JDK 5 times [1]) as "Cached Data Storage". This is
surprising and confusing for everybody already familiar with the
existing "CDS" feature. I'd therefore suggest to move the very last
sentence of the JEP to the very beginning. E.g. something like:

This JEP is an evolution of the existing CDS ("Class Data Sharing")
implementation. In the remainder of the document we will refer to CDS
as "Cached Data Storage" to emphasize its extended functionality
compared to the classic Class Data Sharing.

Another point I think the JEP should address in some more detail is
the effect of "Cached Data Storage" on the overall memory footprint of
the JVM process. The classic "Class Data Sharing" already slightly
increased the memory footprint of the JVM and only amortized if more
than one JVM used the same CDS archive at runtime. Please describe the
effects of the new "Cached Data Storage" on memory footprint.

Finally some minor text corrections:

> CDS is built into the HotSpot VM since JDK 6.

It's actually there since JDK 5, see [1] :)

> Using CDS

The way you describe the manual usage of CDS is "old" and quite
cumbersome. Why not use  the new -XX:+AutoCreateSharedArchive option
which automatically creates the archive if non is available. Or does
-XX:+AOTLoadedClasses not work together with
-XX:+AutoCreateSharedArchive and if so, why not?

> This is can be viewed as..

Remove redundant "is" in the sentence above.

> from CDS assets already present VM memory,

Should probably read "..present in VM memory.."

> such as method profiles and compiled code, can stored as new assets

Should probably read "..can be stored.."

> The implementation CDS already does enforce

Should probably read "The CDS implementation.."

> Therefore, we can use run existing CDS test cases with this option explicitly enabled.

Should probably read "we can use and run existing.."

Regards,
Volker

[1] https://web.archive.org/web/20040604034719/http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.html
[2] https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#creating-dynamic-cds-archive-file-with--xxautocreatesharedarchive

On Thu, Jul 4, 2024 at 7:38 AM John Rose <john.r.rose at oracle.com> wrote:
>
> Dear colleagues,
>
> Having recently delivered a Leyden EA Build of our “premain” work, the Leyden team is very happy to post our first JEP for public review.
>
> https://openjdk.org/jeps/8315737
>
> Covering a subset of the functionality in the EA Build, this JEP describes our plans for introducing, to the JDK, the first course of startup and warmup enhancements which have been “cooking” since last February.
>
> Because CDS is a somewhat obscure technology, and because startup and warmup are very tricky (even refractory) problems in our ecosystem, we are striving to make the JEP as clear and informative as possible.  It covers the nature of the problem, and the past solutions in HotSpot, as well as the present proposal.  (Although there are many excellent and inspiring proposals for this problem beyond HotSpot, this JEP does not attempt to address them; that is for another paper.)  We hope you find it an interesting and useful mix of “high level” and “nitty gritty” details.
>
> Though the actual proposal (the Description) section may seem surprisingly simple, the implications are pervasive and subtle.  As the JEP explains, the proposed changes will be felt all the more in the AOT technologies built on top, as can be seen in our EA Build.
>
> The Non-Goals section gives guidance about where we expect to go after this JEP.
> So if there seems to be a missing piece in this JEP, please look for it first among the non-goals!  We are working on more JEPs to come after this one.  Let’s get this one sorted so we can do more.
>
> Like the EA Build, this work has not been possible without the participation of the Java community.  Special thanks to our Red Hat and Spring colleagues, and to everyone who is now sampling that EA Build.  Also, special thanks to our very demanding early reviewers, notably Alex Buckley, Brian Goetz, my co-authors Dan and Ioi, and the other members of the premain team.
>
> Your comments on the JEP will surely improve it as well.
>
> Best wishes,
>
> — John Rose