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

[Claes Redestad]

I updated open.01 with a reworked microbenchmark that uses
JarFile.getInputStream to trigger the "maybe instantiate
the JAR verifier" logic.

This exercise the code being optimized in this patch better,
while also being a little bit more realistic. Improvements around
1.3x-1.5x across tested jar variants, along with 20-35% allocation
reductions. See the source for sampled results.

Thanks!

/Claes

On 2020-05-08 12:57, Claes Redestad wrote:
> Hi Max,
> 
> On 2020-05-08 09:08, Weijun Wang wrote:
>> JarFile.java:
>>
>> 734: extra new line?
> 
> Fixed
> 
>> 930: Remove or rewrite the comment.
> 
> Did even better: now that I find the position of the manifest during
> initCEN, this method should always call JUZFA.getManifest(this, false);
> - which is both a simplification and an optimization.
> 
>>
>> ZipFile.java:
>>
>> 49: seems not used
> 
> Fixed
> 
>>
>> Please add links to each other between 
>> src/java.base/share/classes/sun/security/util/SignatureFileVerifier.java::isBlockOrSF 
>> and 
>> src/java.base/share/classes/java/util/zip/ZipFile.java::isSignatureRelated. 
>> The 2nd method can also be static.
>>
>> I assume you cannot put ZipFile::isSignatureRelated into 
>> SignatureFileVerifier.java, right?
> 
> Right, that wouldn't be great for either since ZipFile operates directly
> on UTF-8 encoded bytes for performance, while SignatureFileVerifier
> works on Strings.
> 
> What we can do though is to add in an assert that the result of
> ZF::isSignatureRelated matches that of SFV::isBlockOrSF - which should
> ensure. I also added a note to SignatureFileVerifier::isBlockOfSF to
> keep these in sync:
> 
> http://cr.openjdk.java.net/~redestad/8244624/open.01/
> 
> Testing: re-running tier1+2
> 
>>
>> Thanks,
>> Max
>>
>> p.s. How do you run the benchmark test? Both locally and on mach5.
> 
> See doc/testing.md
> 
> Basically:
> Configure with --with-jmh (jib does this automatically)
> make build-microbenchmark
> $JDK/bin/java -jar build/$CONF/images/test/micro/benchmarks.jar JarFileMeta
> 
> Thanks!
> 
> /Claes
>>
>>> On May 8, 2020, at 5:28 AM, 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
>>