Draft JEP 8315737: AOT Linked Classes

[John Rose]

On 8 Jul 2024, at 6:52, Volker Simonis wrote:

> Hi Jon,
>
> Thanks for the update and great to see this moving forward.

Wow, thank you for the excellent comments and suggestions.

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

The flow of the JEP is designed for the majority of folks, to whom CDS is a new thing.  So I won’t be adding extra detail up there.  But I did put some more explanation further down, and added a link from the first paragraph to that explanatory section.

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

I wrote a paragraph on this but then decided it was too much information for this JEP.  There probably already too much in there.

Here’s what I wrote and then deleted:

>> Historically, CDS has a secondary goal of reducing footprint by sharing CDS file pages across VM processes.  The present work does not modify this goal.  It should be noticed, however, that modern CDS deployments often lose much of their sharing due to dynamic relocations, because mapping addresses are made unpredictable by current practices such as ASLR.  With any AOT technology like CDS, there is always a tension between either under-provisioning, which may force VM startup to consume more CPU as it repeats work, or else over-provisioning, which may cause unused resources to be consume memory.  Future work may further address these tradeoffs.

There’s only so many times you can say “yeah, we know about that, and trust us, we want to get around to it”.  Note the Non-Goals section as well.  I don’t think footprint needs its own entry there either.

> Finally some minor text corrections:

Many thanks!

— John