File Format Investigation: jimage

[Severin Gehwolf]

On Tue, 2023-02-14 at 16:50 -0500, Brian Goetz wrote:
>  Nice analysis and reverse-engineering.  (Also, nice monospace font;
> is that Roboto?)  

Thanks. The font is Roboto Mono.

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

Perhaps it would be useful to define "format" in this context. Is
"format" a single file? Could it be many? Perhaps so.

In terms of composablility it doesn't seem strictly necessary as the
current way how jlink (or whatever the future interface to drive the
condenser pipeline is) works, is to also include transformations for
binaries and shared objects.

Thanks,
Severin