RFR: 8259065: Optimize MessageDigest.getInstance
Valerie Peng
valeriep at openjdk.java.net
Wed Jan 6 20:08:56 UTC 2021
On Wed, 6 Jan 2021 02:29:58 GMT, David Schlosnagle <github.com+54594+schlosna at openjdk.org> wrote:
>> Since much of the cost is now the creation of the MessageDigest itself, I added a microbenchmark to stat this overhead:
>>
>> Benchmark (digesterName) Mode Cnt Score Error Units
>> GetMessageDigest.cloneInstance MD5 avgt 30 124.922 ± 5.412 ns/op
>> GetMessageDigest.cloneInstance:·gc.alloc.rate.norm MD5 avgt 30 280.015 ± 0.001 B/op
>>
>> That means there's no added allocation overhead of calling `MessageDigest.getInstance(digesterName)` compared to cloning an existing instance - which means we get almost all of the benefits without resorting to tricks as caching and cloning an instance at call sites such as the one in `UUID::nameUUIDFromBytes`. The remaining 20ns/op difference should be negligible.
>
> Nice speedup for all `MessageDigest.getInstance` and `Provider.getService` invocations and improves on removing the scalability bottlenecks of `Provider.getService` beyond [JDK-7092821](https://bugs.openjdk.java.net/browse/JDK-7092821) (and related [JDK-8080273](https://bugs.openjdk.java.net/browse/JDK-8080273) & [JDK-8172827](https://bugs.openjdk.java.net/browse/JDK-8172827)). This will also allow removing some longstanding `MessageDigest#clone` workarounds such as in Guava https://github.com/google/guava/issues/1197 .
Thanks for looking into this. I will take a look.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1933
More information about the security-dev
mailing list