<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 2/14/2023 1:50 PM, Brian Goetz
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:471744e2-d638-c441-0e39-e4127c972371@oracle.com">
      
      <font size="4"><font face="monospace">Nice analysis and
          reverse-engineering.  (Also, nice monospace font; is that
          Roboto?)  <br>
          <br>
          I agree with your list of "useful properties"; storing
          existing JVM artifacts (such as CDS archives) as well as new
          JVM artifacts (heap object snapshots, AOT) are going to be
          required, and jimage is a candidate here (though not the only
          one.)  Similarly, there's an evaluation to be done, for
          example, whether to update the CDS format to store more things
          (AOT, more general heap object storage), or to have separate
          stores for these, or to overhaul the format.  But whichever is
          chosen, embedding in jimage seems a possibility.  <br>
          <br>
          The one assumption that I would quibble with is the suggestion
          for using jimage as an intermediate format in the condenser
          pipeline.  It seems credible that separate intermediate and
          final formats will be preferable to a one-size-fits-all, since
          the needs of the next condenser in the pipeline at build time
          are not likely to be the same as those of the VM at runtime,
          and formats like CDS are optimized for the VM to consume them,
          not to be, for example, easily queried and updated.  <br>
          <br>
        </font></font></blockquote>
    <br>
    FYI,<br>
    <br>
    For debugging purposes, CDS can be generated with a map file that
    describes its contents in detail.<br>
    <br>
    One thing on my todo list is to generate an hprof file as part of
    the CDS dump. You can load it into an hprof viewer to examine the
    archived Java objects.<br>
    <br>
    But I agree that trying to extract individual elements from the CDS
    archive is not easy, and probably not worth doing.<br>
    <br>
    Thanks<br>
    - Ioi<br>
    <br>
    <br>
    <blockquote type="cite" cite="mid:471744e2-d638-c441-0e39-e4127c972371@oracle.com"><font size="4"><font face="monospace"> Cheers,<br>
          -Brian<br>
          <br>
          <br>
        </font></font><br>
      <div class="moz-cite-prefix">On 2/14/2023 8:39 AM, Severin Gehwolf
        wrote:<br>
      </div>
      <blockquote type="cite" cite="mid:4a1ea6468eb22994986dc6ce01a2350d1f57a6e3.camel@redhat.com">
        <pre class="moz-quote-pre" wrap="">Hi,

We have been looking at lib/modules (a.k.a jimage) as a potential
candidate format for Project Leyden. Along the way, I've documented how
the file is structured[1] and used in its current form. The document
discussing jimage in the context of Leyden is here:

<a class="moz-txt-link-freetext" href="https://cr.openjdk.org/~sgehwolf/leyden/jimage_file_format_investigation_leyden.pdf" moz-do-not-send="true">https://cr.openjdk.org/~sgehwolf/leyden/jimage_file_format_investigation_leyden.pdf</a>

Looking forward to your feedback!

Thanks,
Severin

[1] <a class="moz-txt-link-freetext" href="https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png" moz-do-not-send="true">https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png</a>

</pre>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>