<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 7/11/24 12:54 AM, Sanne Grinovero
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <div>Apologies for intervening with possibly very naive
          questions, as I'm new here - but very curious about this:</div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Wed, Jul 10, 2024 at
            11:43 PM <<a href="mailto:ioi.lam@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">ioi.lam@oracle.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
            On 7/10/24 6:41 AM, Volker Simonis wrote:<br>
            > Hi Ioi,<br>
            ><br>
            > Thanks for the clarification. I wasn't aware of the
            fact, that only<br>
            > static CDS archives can contain archived heap objects.
            The official<br>
            > CDS documentation [1] is also not mentioning this. In
            contrary, it<br>
            > states that:<br>
            ><br>
            >> 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.<br>
            > So maybe that documentation should be updated to make
            it clear that<br>
            > static CDS archives are more powerful?<br>
            <br>
            I have filed <a href="https://bugs.openjdk.org/browse/JDK-8336147" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8336147</a><br>
            <br>
            <br>
            > Is there a conceptual reason for why dynamic archives
            can not contain<br>
            > heap objects or is this just an implementation issue
            that could be<br>
            > solved? Maybe because G1 can currently only map a
            single heap region<br>
            > from file?<br>
            <br>
            The reasons that heap objects cannot be stored in the
            dynamic archive:<br>
            <br>
            - The dynamic dump happens at the end of program execution.
            GC might <br>
            have moved the objects around. If there’s a reference from
            the <br>
            achievable objects from the dynamic archive that points to
            the <br>
            archivable objects in the static archive, keeping track of
            that is <br>
            difficult.<br>
          </blockquote>
          <div><br>
          </div>
          <div>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?</div>
          <div>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?</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Hi Sanne,<br>
    <p>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.</p>
    <p>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).<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>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.</div>
          <div> </div>
          <div><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            - The dynamic run may mutate objects in the static archive.
            For example, <br>
            for invokedynamic support, if we have a MethodType for a
            class in the <br>
            dynamic archive, this MT needs to be entered into a global
            hashtable <br>
            that’s rooted in the static archive <br>
            (java.lang.invoke.MethodType::internTable).<br>
            <br>
            Instead of just fixing the 2-level problem between static
            and dynamic <br>
            archives, folks like John Rose and Dan Heidinga are working
            on general <br>
            designs that would support multiple groups of archived heap
            objects that <br>
            have cross references between these groups.<br>
            <br>
            In the near future, Leyden optimization will be based on the
            static <br>
            archive only, as many optimizations rely on snapshots of
            heap objects.<br>
          </blockquote>
          <div><br>
          </div>
          <div>With that, do you mean that many more optimizations are
            reserved for after the new design is implemented?</div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
    <p>Not exactly.</p>
    <p>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.</p>
    <p>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.<br>
    </p>
    <p><br>
    </p>
    <p>Thanks</p>
    <p>- Ioi<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:CAA5_-WZGAguPDrWP32JdK5oKZnZE8L93PuGb-z3OxcZd5vEr9w@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div>Many thanks</div>
          <div> -- Sanne</div>
          <div><br>
          </div>
          <div> </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <br>
            <br>
            Thanks<br>
            <br>
            - Ioi<br>
            <br>
            <br>
            <br>
            ><br>
            > Thank you and best regards,<br>
            > Volker<br>
            ><br>
            > [1] <a href="https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://docs.oracle.com/en/java/javase/22/docs/specs/man/java.html#application-class-data-sharing</a><br>
            ><br>
            > On Tue, Jul 9, 2024 at 7:32 AM <<a href="mailto:ioi.lam@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">ioi.lam@oracle.com</a>>
            wrote:<br>
            >> On 7/8/24 6:52 AM, Volker Simonis wrote:<br>
            >><br>
            >> The way you describe the manual usage of CDS is
            "old" and quite<br>
            >> cumbersome. Why not use the new
            -XX:+AutoCreateSharedArchive option<br>
            >> which automatically creates the archive if non is
            available. Or does<br>
            >> -XX:+AOTLoadedClasses not work together with<br>
            >> -XX:+AutoCreateSharedArchive and if so, why not?<br>
            >><br>
            >> -XX:+AutoCreateSharedArchive is for creating
            dynamic CDS archives only. It cannot be used for creating
            static CDS archives.<br>
            >><br>
            >> -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:<br>
            >><br>
            >>      JDK-8293336 Store LambdaForms in CDS archive
            heap<br>
            >><br>
            >> JDK-8293336 works only for the static CDS archive
            (it requires archiving Java heap objects, which is not
            supported by dynamic CDS archives).<br>
            >><br>
            >> Thanks<br>
            >><br>
            >> - Ioi<br>
            <br>
          </blockquote>
        </div>
      </div>
    </blockquote>
  </body>
</html>