RFR: 8321620: Optimize JImage decompressors

[Glavo]

On Sun, 14 Jan 2024 17:16:37 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Pre-existing issue here is that it seems we don't handle compressed resources that can't fit in a single byte[], yet we take the overhead of storing uncompressed/compressed size as longs (4+4 byte overhead per entry). I guess we should either add code to handle huge entries or optimize the compressed header to store int sizes.

This limitation is so deep-rooted that it is difficult to resolve it for the time being. But I don't think this is causing any problems for the time being. There is no need to put an overly large resource in a jimage file, it will be better placed elsewhere.

But even so, I think it's appropriate to store the size as 64 bits, which will make it easier to lift this restriction in the future. If you want the size of the metadata, I think it is more appropriate to compress the metadata. I tried using zstd to compress the metadata in [JApp](https://github.com/Glavo/japp) and got good results. We might be able to do this in jimage as well.

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

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