#14632 showed that coalescing loads in the `ZipUtils` utility methods could improve performance in zip-related microbenchmarks, but doing so would increase startup overheads. Progress was stalled as we backed out some related early use of `ByteArray(LittleEndian)` and started exploring merge store optimizations in C2.
In this PR I instead suggest using `Unsafe` directly to coalesce `short`, `int`, and `long` reads from zip data. Even with explicit bounds checking to ensure these utilities are _always_ safe there are significant improvements both to lookup speed and speed of opening zip files (most if not all bounds checks are optimized away): make test TEST=micro:java.util.zip.ZipFile Name (size) Cnt Base Error Test Error Unit Change GetEntry.getEntryHit 512 15 37.999 ± 0.841 34.641 ± 0.389 ns/op 1.10x (p = 0.000*) GetEntry.getEntryHit 1024 15 39.557 ± 0.523 36.959 ± 1.488 ns/op 1.07x (p = 0.000*) GetEntry.getEntryHitUncached 512 15 69.250 ± 0.931 64.851 ± 0.987 ns/op 1.07x (p = 0.000*) GetEntry.getEntryHitUncached 1024 15 71.628 ± 0.307 67.927 ± 0.714 ns/op 1.05x (p = 0.000*) GetEntry.getEntryMiss 512 15 22.961 ± 0.336 22.825 ± 0.188 ns/op 1.01x (p = 0.158 ) GetEntry.getEntryMiss 1024 15 22.940 ± 0.115 23.502 ± 0.273 ns/op 0.98x (p = 0.000*) GetEntry.getEntryMissUncached 512 15 35.886 ± 0.429 35.598 ± 1.296 ns/op 1.01x (p = 0.395 ) GetEntry.getEntryMissUncached 1024 15 38.168 ± 0.911 36.141 ± 0.356 ns/op 1.06x (p = 0.000*) Open.openCloseZipFile 512 15 62425.563 ± 997.455 56263.401 ± 896.892 ns/op 1.11x (p = 0.000*) Open.openCloseZipFile 1024 15 117491.250 ± 962.928 108055.491 ± 1595.577 ns/op 1.09x (p = 0.000*) Open.openCloseZipFilex2 512 15 62974.575 ± 911.095 57996.388 ± 910.929 ns/op 1.09x (p = 0.000*) Open.openCloseZipFilex2 1024 15 119164.769 ± 1756.065 108803.468 ± 929.483 ns/op 1.10x (p = 0.000*) * = significant This PR also address some code duplication in `ZipUtils`. An appealing alternative would be to implement a merge load analogue to the merge store optimizations in C2. Such optimizations would be very welcome since it would improve similar code outside of java.base (jdk.zipfs has some duplicate code that is left untouched) and reduce the need for `Unsafe` trickery. This enhancement and the microbenchmarks could then be used as verification and the `Unsafe` code backed out. ------------- Commit messages: - Add main method to ZipFileOpen, enabling use as a startup benchmark - Remove ForceInline after verification it's not needed - Use Unsafe to coalesce reads in java.util.zip.ZipUtils Changes: https://git.openjdk.org/jdk/pull/21377/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21377&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341594 Stats: 96 lines in 3 files changed: 16 ins; 22 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/21377.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21377/head:pull/21377 PR: https://git.openjdk.org/jdk/pull/21377
