<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">I think we're on the same page
        about "what should you be able to do", though clearly we need
        some more refined terminology for describing it, since there are
        a number of possible states.<br>
        <br>
        <br>
      </font></font><br>
    <div class="moz-cite-prefix">On 2/15/2023 9:48 AM, Dan Heidinga
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CAJq4Gi7KwRqbRR3-L1f8WY1z0zu=WE-GVMGQN5E9XvrbDO0uuw@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr"><br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Wed, Feb 15, 2023 at 9:36
            AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@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">
            <div> <font size="4"><font face="monospace">The devil is in
                  the details, of course; different condensers may do
                  different degrees of condensation.  You cited as your
                  use case:<br>
                  <br>
                  <blockquote type="cite">starting from a JVM and a set
                    of modules, we might apply some condensers (jlink
                    being the tool for such activities today), and
                    produce a resulting image.  </blockquote>
                  <br>
                  The key word that is confusing us here is *some*;
                  let's say you're applying condensers A, B, and C. 
                  Should we produce a complete, runnable, binary
                  application image with AppCDS archives and all that
                  between A and B, and then again between B and C? 
                  That's what I mean by "intermediate format".  <br>
                  <br>
                </font></font></div>
          </blockquote>
          <div><br>
          </div>
          <div>I think we're on the same page.  My expectation was I'd
            have a runnable image at the end of A->B->C and could
            then, assuming non-terminal condensers, either execute it or
            feed it through a new condenser pass of D->E->F.</div>
          <div><br>
          </div>
          <div>--Dan</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">
            <div><font size="4"><font face="monospace"> </font></font><br>
              <div>On 2/15/2023 9:16 AM, Dan Heidinga wrote:<br>
              </div>
              <blockquote type="cite">
                <div dir="ltr">
                  <div dir="ltr"><br>
                  </div>
                  <br>
                  <div class="gmail_quote">
                    <div dir="ltr" class="gmail_attr">On Tue, Feb 14,
                      2023 at 4:50 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@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">
                      <div> <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. </font></font></div>
                    </blockquote>
                    <div><br>
                    </div>
                    <div>"Intermediate format" doesn't quite capture our
                      thinking here.  The assumption was that starting
                      from a JVM and a set of modules, we might apply
                      some condensers (jlink being the tool for such
                      activities today), and produce a resulting image. 
                      This image should both be runnable as is and also
                      be usable as input for further condensation
                      passes.  Mark and I's discussion [0] indicated
                      this was a goal at least for non-terminal
                      condensers (ie: those that haven't "condensed all
                      the way down to a platform-specific executable").</div>
                    <div><br>
                    </div>
                    <div>Does that mean that jimage (or whatever the
                      chosen format ends up being) must be the
                      intermediate form?  Probably not but I think it
                      does put a requirement on the system that
                      condensed images need to be considered as valid
                      inputs to the system.</div>
                    <div><br>
                    </div>
                    <div>Were you thinking of requiring a separate step
                      that converts condensed images to runnable ones? 
                      Where the second step in this process is always
                      required to get a runnable result?</div>
                    <div><br>
                    </div>
                    <div>{ JDK + modules | condensed image }  -->
                      condensers --> condensed image</div>
                    <div>condensed image --> runnable image<br>
                    </div>
                    <div><br>
                    </div>
                    <div>--Dan</div>
                    <div><br>
                    </div>
                    <div>[0] <a href="https://mail.openjdk.org/pipermail/leyden-dev/2022-October/000085.html" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://mail.openjdk.org/pipermail/leyden-dev/2022-October/000085.html</a></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">
                      <div><font size="4"><font face="monospace"> <br>
                            <br>
                            Cheers,<br>
                            -Brian<br>
                            <br>
                            <br>
                          </font></font><br>
                        <div>On 2/14/2023 8:39 AM, Severin Gehwolf
                          wrote:<br>
                        </div>
                        <blockquote type="cite">
                          <pre>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 href="https://cr.openjdk.org/~sgehwolf/leyden/jimage_file_format_investigation_leyden.pdf" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://cr.openjdk.org/~sgehwolf/leyden/jimage_file_format_investigation_leyden.pdf</a>

Looking forward to your feedback!

Thanks,
Severin

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

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