On Tue, 5 Jan 2021 23:08:43 GMT, DellCliff
<[email protected]> 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
