On Fri, 12 Jan 2024 18:45:39 GMT, Glavo <d...@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.
For reference here's my draft idea on a backwards-compatible compressed
compressed header (heh): https://github.com/openjdk/jdk/pull/17433
No significant difference on micros but a modest saving on the archive size.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1892678919
