RFR: 8259065: Optimize MessageDigest.getInstance [v4]

Valerie Peng valeriep at openjdk.java.net
Thu Jan 7 23:56:00 UTC 2021


On Thu, 7 Jan 2021 21:18:22 GMT, Claes Redestad <redestad at openjdk.org> 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


More information about the security-dev mailing list