RFR: 8259498: Reduce overhead of MD5 and SHA digests

[Claes Redestad]

On Wed, 6 Jan 2021 01:27:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hitting up `new MD5()` directly could be a great idea. I expect this would be just as fast as the cache+clone (if not faster), but I'm a bit worried we'd be short-circuiting the ability to install an alternative MD5 provider (which may or may not be a thing we must support..), but it's worth exploring.
>> 
>> Comparing performance of this against a `ByteBuffer` impl is on my TODO. The `VarHandle` gets heavily inlined and optimized here, though, with performance in my tests similar to the `Unsafe` use in `ByteArrayAccess`.
>
> I've identified a number of optimizations to the plumbing behind `MessageDigest.getDigest(..)` over in #1933 that removes 80-90% of the throughput overhead and all the allocation overhead compared to the `clone()` approach prototyped here. The remaining 20ns/op overhead might not be enough of a concern to do a point fix in `UUID::nameUUIDFromBytes`.

Removing the UUID clone cache and running the microbenchmark along with the changes in #1933:

Benchmark                                                  (size)   Mode  Cnt    Score    Error   Units
UUIDBench.fromType3Bytes                                    20000  thrpt   12    2.182 ±  0.090  ops/us
UUIDBench.fromType3Bytes:·gc.alloc.rate                     20000  thrpt   12  439.020 ± 18.241  MB/sec
UUIDBench.fromType3Bytes:·gc.alloc.rate.norm                20000  thrpt   12  264.022 ±  0.003    B/op

The goal now is if to simplify the digest code and compare alternatives.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1855