<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">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">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">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">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">https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote></div></div>