RFR: 8244624: Improve handling of JarFile META-INF resources
Martin Buchholz
martinrb at google.com
Sun May 10 21:45:27 UTC 2020
Looks good to me!
On Sun, May 10, 2020 at 2:07 PM Claes Redestad <claes.redestad at 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.redestad at 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
>
More information about the core-libs-dev
mailing list