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

[Claes Redestad]

On Wed, 18 Jan 2023 16:53:04 GMT, Claes Redestad <redestad 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

Updated micro to vary entry sizes more to ensure we exercise the different code paths through the `hashCode` intrinsic. The new setup generates both longer and shorter entries than before, weighting up the average length a bit by increasing the spread. The longer entries see a proportionately larger speed-up, as expected since they benefit from vectorization. Removed some pointless randomness.

Baseline:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   98832.801 ± 2155.928  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  187373.545 ± 2296.779  ns/op


Patched:

Benchmark                     (size)  Mode  Cnt       Score      Error  Units
ZipFileOpen.openCloseZipFile     512  avgt   15   85574.648 ±  920.477  ns/op
ZipFileOpen.openCloseZipFile    1024  avgt   15  160493.277 ± 3450.928  ns/op

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

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