RFR: 8244624: Improve handling of JarFile META-INF resources

[Martin Buchholz]

Thanks for improving the jar/zip code.
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.
I still like my ancient "ASCII trick" comment.

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