File Format Investigation: jimage

[Brian Goetz]

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.

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/20230214/b9ac7b5a/attachment.htm>