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

[ioi.lam at oracle.com]

On 7/11/24 12:54 AM, Sanne Grinovero wrote:
>
> 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?
>

Hi Sanne,

The dynamic dump happens after (1) the static archive is loaded, and (2) 
the application executes and exits the VM. The archived heap objects in 
the static archive are loaded at (1). Between (1) and (2), multiple GC 
could have happened and moved the archived objects around.

At (2), if we have an object A we want to archive, and A has a pointer 
that points to location 0x1234, we will have no idea whether 0x1234 came 
from the archived objects from the static archive, or something that was 
created between (1) and (2).


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

Not exactly.

We are implementing many new optimizations, but these new optimizations 
can be used only with the static archive. In fact, most new 
optimizations are tied to the new -XX:CacheDataStore flag, which 
specifies the location of a static archive.

We expect that the caching of "system" states can be done without the 
"Egg" API, which is our internal name for resolving the references 
between multiple groups of archived Java objects. However, for user code 
to cache their own objects (e.g., ahead-of-time generation of an 
application-specific hashtable) may need to wait for the Egg API.


Thanks

- Ioi


> 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/8fd7d10c/attachment.htm>