Looks good to me! On Sun, May 10, 2020 at 2:07 PM Claes Redestad <claes.redes...@oracle.com> wrote:
> Hi Martin, > > On 2020-05-10 21:53, Martin Buchholz wrote: > > Thanks for improving the jar/zip code. > > thanks! > > > I wish I had more time to do the same. > > My own superficial review only adds one small suggestion: > > add a comment as to why isSignatureRelated never hits a negative index > > exception. > > Yes, it's a bit subtle and deserves a comment. > > > I still like my ancient "ASCII trick" comment. > > Google "oldest ASCII trick in the book" and the first hit is an article > about this trick (or well, the inverse - but it still counts!). :-) > > Lance only suggested we clarify what that trick is - hope you're OK with > that: > > http://cr.openjdk.java.net/~redestad/8244624/open.02/ > > /Claes > > > > > On Thu, May 7, 2020 at 2:34 PM Claes Redestad <claes.redes...@oracle.com> > wrote: > >> > >> Hi, > >> > >> currently during ZipFile creation, we create an int[] array of pointers > >> to META-INF entries. These are then retrieved from three different > >> places in JarFile. > >> > >> However, JarFile is only interested in some combination a few things: > >> the existence of and name of the META-INF/MANIFEST file, the existence > >> of and the names of various signature related files, i.e., files in > >> META-INF that have a suffix such as .EC, .SF, .RSA and .DSA > >> > >> Refactoring the contract between JarFile and ZipFile means we can filter > >> out such entries that we're not interested when opening the file, and > >> also remove the need to create the String for each entries unless we > >> actually want them: > >> > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8244624 > >> Webrev: http://cr.openjdk.java.net/~redestad/8244624/open.00/ > >> > >> This reduces retained footprint of Jar-/ZipFile by slimming down or > >> removing the Source.metanames array entirely, and a significant speed-up > >> in some cases. > >> > >> In the provided microbenchmark, getManifestFromJarWithManifest and > >> getManifestFromJarWithSignatureFiles doesn't call > >> JUZFA.getMetaInfEntryNames but still see small (~5%) speed-up decrease > >> in allocations. > >> > >> getManifestFromJarWithNoManifest exercise JUZFA.getMetaInfEntryNames in > >> the baseline, and now calls JUZFA.getManifestName. Result is a 1.25x > >> speed-up and 30% reduction in allocations. While unrealistic (most JARs > >> have a META-INF/MANIFEST.MF), this speed-up will translate to a few > >> places - such as when loading classes from potentially-signed JAR files. > >> > >> Testing: tier1-2 > >> > >> Thanks! > >> > >> /Claes >
