RFR JDK-8172921: Zip filesystem performance improvement and code cleanup
claes.redestad at oracle.com
Tue Jan 17 23:24:31 UTC 2017
thanks for doing this!
Looks good - I stumbled on the ZipPath::getResolved changes at first,
but they seem sound and I can see how the previous test was likely to
unnecessarily create a new byte on most regular files.
Code formatting seems unintentionally messed up in places, especially
ZipCoder$UTF8 has a chunk of commented out code that should likely be
On 2017-01-17 23:39, Xueming Shen wrote:
> Please review the following changes for zipfs implementation.
> issue: https://bugs.openjdk.java.net/browse/JDK-8172921
> webrev: http://cr.openjdk.java.net/~sherman/8172921/webrev/
> javac has moved to use zipfs (instead of ZipFile) to access jar files in
> jdk9. Here are
> some changes to improve the performance of access time and footprint
> (reduce the
> unnecessary object allocation ...) The improvement has been measured by
> the jmh
> benchmark test as
> with the benchmark sores (before-OLD/after-NEW) at:
> The main change is to change the internal directory path representation
> from the
> zip specific format (directory name ends with "/", "/dir/" for directory
> ".dir" for
> example) to the "normalized" form with the tailing "/", which reduces
> the back and
> forth conversion between the normal "unix style" path and the "zip
> style" path when
> doing path creation, path lookup and entry access, which also simplified
> the entry
> lookup logic.
> We are seeing pretty good performance improvement.
> There is another change, which involves the API change, for the
> "non-existing" path
> look up (which shows pretty bad numbers as ZFS_ExistsNG"), is not
> included in this
> patch. I hope we can address that as well in jdk9, but probably in
> another patch.
More information about the nio-dev