RFR: 8259498: Reduce overhead of MD5 and SHA digests
redestad at openjdk.java.net
Fri Jan 8 22:41:06 UTC 2021
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`.
More information about the core-libs-dev