Hi Sherman, 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. Nits: Code formatting seems unintentionally messed up in places, especially ZipCoder.java. ZipCoder$UTF8 has a chunk of commented out code that should likely be removed. /Claes On 2017-01-17 23:39, Xueming Shen wrote:
Hi, 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 http://cr.openjdk.java.net/~sherman/8172921/MyBenchmark.java with the benchmark sores (before-OLD/after-NEW) at: http://cr.openjdk.java.net/~sherman/8172921/scores 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. Thanks, Sherman
