On Tue, 11 Jul 2023 16:35:51 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
> This PR adds an internal method to calculate hash code from the provided > integer array, offset and length into that array, and the initial hash code > value. > > Current options for calculating a hash code for int[] are inflexible. It's > either ArraysSupport.vectorizedHashCode with an offset, length and initial > value, or Arrays.hashCode with just an array. > > For an arbitrary int[], unconditional vectorization might be unwarranted or > puzzling. Unfortunately, it's the only hash code method that operates on an > array subrange or accepts the initial hash code value. > > A more convenient method could be added and then used, for example, here: > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java#L1076-L1083 > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/java/util/ArrayList.java#L669-L680 > > * > https://github.com/openjdk/jdk/blob/0ef03f122866f010ebf50683097e9b92e41cdaad/src/java.base/share/classes/sun/security/pkcs10/PKCS10.java#L356-L362 > > This PR adds such a method and provides tests for it. Additionally, this PR > adds tests for `null` passed to `java.util.Arrays.hashCode` overloads, > behaviour which was specified but untested. Yes, it should have been `unsignedHashCode`. Adding a layer of `ArraysSupport.hashCode` methods with no `basicType` parameter exposed, which in turn calls a renamed `vectorizedHashCode` (`@IntrinsicCandidate private static int internalHashCode`?) seem like a reasonable cleanup on the face of it. Assuming we can retain performance characteristics. One complication is that we'd also need to expose a `utf16HashCode` that takes a `byte[]` and interprets it as holding `char` values. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14831#issuecomment-1655612832
