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