RFR: 8300493: Use ArraysSupport.vectorizedHashCode in j.u.zip.ZipCoder

[Claes Redestad]

On Fri, 20 Jan 2023 11:25:22 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> `ZipCoder::checkedHashCode` emulates `StringLatin1::hashCode` but operates on a `byte[]` subrange. It can profitably use the recently introduced `ArraysSupport::vectorizedHashCode` method to see a speed-up, which translates to a small but significant speed-up on `ZipFile` creation.
>> 
>> Before:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   83007.325 ± 1446.716  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  154550.631 ± 2166.673  ns/op
>> 
>> After:
>> 
>> Benchmark                     (size)  Mode  Cnt       Score      Error  Units
>> ZipFileOpen.openCloseZipFile     512  avgt   15   79512.902 ±  814.449  ns/op
>> ZipFileOpen.openCloseZipFile    1024  avgt   15  147892.522 ± 2744.017  ns/op
>
> test/micro/org/openjdk/bench/java/util/zip/ZipFileOpen.java line 69:
> 
>> 67: 
>> 68:                 ename += "long-entry-name-"  + (random.nextInt(90000) + 10000)  + "-" + i;
>> 69:                 zos.putNextEntry(new ZipEntry(ename));
> 
> Would it be worth to add some random sized data when the entries are created to allow for getting a bit more insight, or  perhaps do that in a separate benchmark>

I was experimenting with varying the entry names length to see what - if any - impact it had and saw a small effect on the micro. It does make more sense to vary lengths now that very long names will take different paths in the vectorized intrinsic. I'll see what I can do without overengineering this.

-------------

PR: https://git.openjdk.org/jdk/pull/12077