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.
-------------
Commit messages:
- Update ZipDecompressor
Changes: https://git.openjdk.org/jdk/pull/17405/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17405&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8321620
Stats: 21 lines in 1 file changed: 10 ins; 5 del; 6 mod
Patch: https://git.openjdk.org/jdk/pull/17405.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/17405/head:pull/17405
PR: https://git.openjdk.org/jdk/pull/17405
