[External] : Re: Draft JEP 8315737: AOT Linked Classes

[Sanne Grinovero]

Apologies for intervening with possibly very naive questions, as I'm new
here - but very curious about this:

On Wed, Jul 10, 2024 at 11:43 PM <ioi.lam at oracle.com> wrote:

>
> On 7/10/24 6:41 AM, Volker Simonis wrote:
> > Hi Ioi,
> >
> > Thanks for the clarification. I wasn't aware of the fact, that only
> > static CDS archives can contain archived heap objects. The official
> > CDS documentation [1] is also not mentioning this. In contrary, it
> > states that:
> >
> >> The names "static" and "dynamic" are used for historical reasons. The
> only significance is that the "static" archive is loaded first and the
> "dynamic" archive is loaded second.
> > So maybe that documentation should be updated to make it clear that
> > static CDS archives are more powerful?
>
> I have filed https://bugs.openjdk.org/browse/JDK-8336147
>
>
> > Is there a conceptual reason for why dynamic archives can not contain
> > heap objects or is this just an implementation issue that could be
> > solved? Maybe because G1 can currently only map a single heap region
> > from file?
>
> The reasons that heap objects cannot be stored in the dynamic archive:
>
> - The dynamic dump happens at the end of program execution. GC might
> have moved the objects around. If there’s a reference from the
> achievable objects from the dynamic archive that points to the
> archivable objects in the static archive, keeping track of that is
> difficult.
>

As someone who has no clue about how this is actually implemented, I find
this puzzling: since the program is being terminated, why would GC still be
allowed to actively move things around?
I would have expected at this point for the heap to be "frozen": GC is
terminated first, and only then the dump would be captured?

Is it the case that GC is a potentially necessary service to the process of
capturing the dump? I would have assumed some separation in the design, to
have the dumping process run in its own heap or its own process altogether.


- The dynamic run may mutate objects in the static archive. For example,
> for invokedynamic support, if we have a MethodType for a class in the
> dynamic archive, this MT needs to be entered into a global hashtable
> that’s rooted in the static archive
> (java.lang.invoke.MethodType::internTable).
>
> Instead of just fixing the 2-level problem between static and dynamic
> archives, folks like John Rose and Dan Heidinga are working on general
> designs that would support multiple groups of archived heap objects that
> have cross references between these groups.
>
> In the near future, Leyden optimization will be based on the static
> archive only, as many optimizations rely on snapshots of heap objects.
>

With that, do you mean that many more optimizations are reserved for after
the new design is implemented?

Many thanks
 -- Sanne



>
>
> Thanks
>
> - Ioi
>
>
>
> >
> > Thank you and best regards,
> > Volker
> >
> > [1]
> https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing
> >
> > On Tue, Jul 9, 2024 at 7:32 AM <ioi.lam at oracle.com> wrote:
> >> On 7/8/24 6:52 AM, Volker Simonis wrote:
> >>
> >> 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?
> >>
> >> -XX:+AutoCreateSharedArchive is for creating dynamic CDS archives only.
> It cannot be used for creating static CDS archives.
> >>
> >> -XX:+AOTLoadedClasses works for both dynamic and static CDS archives.
> However, as part of this JEP, to demonstrate its promises, we will also
> implement one significant optimization that relies on -XX:+AOTLoadedClasses:
> >>
> >>      JDK-8293336 Store LambdaForms in CDS archive heap
> >>
> >> JDK-8293336 works only for the static CDS archive (it requires
> archiving Java heap objects, which is not supported by dynamic CDS
> archives).
> >>
> >> Thanks
> >>
> >> - Ioi
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20240711/5f315eb8/attachment.htm>