RFR: 8321620: Optimize JImage decompressors

[Claes Redestad]

On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <duke at openjdk.org> wrote:

> I generated runtime images using `jlink --compress 2 --add-modules java.se,jdk.unsupported,jdk.management` and then ran the following JMH benchmark:
> 
> 
> @Warmup(iterations = 10, time = 2)
> @Measurement(iterations = 5, time = 3)
> @Fork(value = 1, jvmArgsAppend = {"-XX:+UseG1GC", "-Xms8g", "-Xmx8g", "--add-exports=java.base/jdk.internal.jimage=ALL-UNNAMED"})
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @State(Scope.Benchmark)
> public class Decompress {
> 
>     private static final ImageReader READER = ImageReaderFactory.getImageReader();
>     private static final ImageLocation LOC = READER.findLocation("java.base", "java/lang/String.class");
> 
>     @Benchmark
>     public ByteBuffer test() {
>         return READER.getResourceBuffer(LOC);
>     }
> 
> }
> 
> 
> 
> This is the result:
> 
> 
> Zip
> 
> Benchmark                           Mode  Cnt       Score       Error   Units        Score       Error   Units
> Decompress.test                     avgt    5  194237.534 ±  1026.180   ns/op   152855.728 ± 16058.780   ns/op   (-21.30%)
> Decompress.test:gc.alloc.rate       avgt    5    1197.700 ±     6.306  MB/sec      464.278 ±    47.465  MB/sec
> Decompress.test:gc.alloc.rate.norm  avgt    5  243953.338 ±     5.810    B/op    74376.291 ±     2.175    B/op   (-69.51%)
> Decompress.test:gc.count            avgt    5       2.000              counts        1.000              counts
> Decompress.test:gc.time             avgt    5       4.000                  ms        3.000                  ms
> 
> 
> The results show that memory allocation is reduced by 70% while decompression speed is significantly improved.

It'd be very interesting to see zstd compression applied in this context to see how it'd stack up w.r.t archive size, speed of decompression and so on. 

In this specific case we'd probably have to keep the 4-byte magic marker intact (it might be possible to rid us of this), then compress the remainder (25 bytes) and store the size (a byte might be enough). For reference with regular zip on representative data I can squeeze headers down then from 29 to 22-24 bytes. In #17433 I'm down to 12 bytes (including marker) with little to no overhead. I'm not going to pursue getting #17433 integrated (for now), but it might be a nice little piece of a larger puzzle.

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

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