RFR: 8259065: Optimize MessageDigest.getInstance [v4]
Claes Redestad
redestad at openjdk.java.net
Thu Jan 7 21:23:21 UTC 2021
On Thu, 7 Jan 2021 19:50:44 GMT, Valerie Peng <valeriep at openjdk.org> wrote:
>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Address review comments from @valeriep
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1933
More information about the security-dev
mailing list