RFR: 8321620: Optimize JImage decompressors

[Glavo]

On Mon, 15 Jan 2024 16:08:35 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I'd very much welcome support for zstd, both for resource content and metadata. A larger JEP-sized project, that.
> 
> I have run a quick experiment with adding a more compact header format (16-bit sizes for the four fields) and on a `jlink --compress 2 --add-modules java.se,jdk.unsupported,jdk.management` it reduces the jimage size by about 0.9% (33279195 vs 32983412 bytes). Throughput might take a small hit. I'm not sure I have time right now to get tested and PR'd but I'll post the draft after sponsoring this.

>From my experience on the JApp project, if compressed metadata is implemented, the size of these fields may be irrelevant.

In the early development stage of JApp, I used 32-bit integers to store metadata such as resource size. But after using zstd to compress the metadata, I was surprised to find that storing them as 64-bit integers can actually reduce the file size for some test cases. The compression algorithm does the work for me, so I no longer need to care about these details.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892821541