File Format Investigation: jimage

[Dan Heidinga]

On Tue, Feb 14, 2023 at 4:50 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> Nice analysis and reverse-engineering.  (Also, nice monospace font; is
> that Roboto?)
>
> 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.
>
> 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.
>

"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").

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.

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?

{ JDK + modules | condensed image }  --> condensers --> condensed image
condensed image --> runnable image

--Dan

[0] https://mail.openjdk.org/pipermail/leyden-dev/2022-October/000085.html


>
>
> Cheers,
> -Brian
>
>
>
> On 2/14/2023 8:39 AM, Severin Gehwolf wrote:
>
> 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:
> https://cr.openjdk.org/~sgehwolf/leyden/jimage_file_format_investigation_leyden.pdf
>
> Looking forward to your feedback!
>
> Thanks,
> Severin
>
> [1] https://cr.openjdk.org/~sgehwolf/leyden/jimage_visualization_1.png
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/leyden-dev/attachments/20230215/1c7c0640/attachment.htm>