RFR: 8259498: Reduce overhead of MD5 and SHA digests

[Claes Redestad]

On Tue, 5 Jan 2021 23:08:43 GMT, DellCliff <github.com+14116124+DellCliff at openjdk.org> wrote:

>> Since `java.util.UUID` and `sun.security.provider.MD5` are both in `java.base`, would it make sense to create new instances by calling `new MD5()` instead of `java.security.MessageDigest.getInstance("MD5")` and bypassing the whole MessageDigest logic?
>
> Are you sure you're not ending up paying more using a VarHandle and having to cast and using a var args call `(long) LONG_ARRAY_HANDLE.get(buf, ofs);` instead of creating a ByteBuffer once via `ByteBuffer.wrap(buffer).order(ByteOrder.nativeOrder()).asLongBuffer()`?

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`.

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

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