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

[Brent Christian]

Looks good, Claes.

Just one small question:

src/java.base/share/classes/java/util/jar/JarFile.java

  759         } catch (IOException | IllegalArgumentException ex) {

Why the addition of IllegalArgumentException ?


-Brent

On 5/10/20 2:07 PM, Claes Redestad 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