On Thu, 7 Jan 2021 21:18:22 GMT, Claes Redestad <[email protected]> wrote:
>> src/java.base/share/classes/java/security/Provider.java line 1072:
>>
>>> 1070: }
>>> 1071: public int hashCode() {
>>> 1072: return 31*31 + type.hashCode()*31 + algorithm.hashCode();
>>
>> Well, perhaps we just revert to Objects.hash(...) (better readability and
>> potential future enhancement in case one is available)? Or, if we want to
>> adopt the same calculation based on current Objects.hash(..) impl, the 31*31
>> part doesn't not seem to be too useful and can be removed for this
>> particular case.
>
> Robustly optimizing the JIT so that `Objects.hash` can avoid creating the
> `Object[]` might be further off than we'd like to think.
>
> I think the one-liner proposed here is a good tradeoff between performance
> and maintainability/readability in a _global_ sense: this one-liner avoids
> non-trivial overhead and allocation that might otherwise still be a strong
> enough motivator to cache calls to `MessageDigest.getInstance` at call-sites
> such as in `UUID::nameUUIDFromBytes`.
>
> Removing the 31*31 factor shouldn't hurt how well-distributed hashes get,
> just shuffle things around. I'll remove it.
Ok, all looks good now.
Thanks~
-------------
PR: https://git.openjdk.java.net/jdk/pull/1933
