RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached

[Claes Redestad]

On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> I have to say that introducing a ThreadLocal here seems like a step in the wrong direction. With a ThreadLocal, if I read this correctly, a MessageDigest will be cached with each thread that ever calls this API, and it won't be garbage collected until the thread dies. Some threads live indefinitely, e.g., the ones in the fork-join common pool. Is this what we want? Is UUID creation so frequent that each thread needs its own, or could thread safety be handled using a simple locking protocol?
>> 
>> Fair enough; the solution proposed by Claes in #1855 seems to be a better alternative.
>> 
>> Currently, I will keep this PR open but I expect this to be superseded by the latter.
>
> Hi Claes,
> Would flattening the state of MD5 bring any further improvements?
> https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083

> Hi Claes,
> Would flattening the state of MD5 bring any further improvements?
> [plevart at 92bf48f](https://github.com/plevart/jdk/commit/92bf48ff58f0ce9648e49466dbf1befebbf49083)

I think it might, marginally, but it seemed to me that the implCompress0 MD5 intrinsic is using `state` so I've not tried that yet since rewriting and checking the intrinsic code is a lot of work. (I've blogged about my experiments in this area and mentioned this issue in passing: https://cl4es.github.io/2021/01/04/Investigating-MD5-Overheads.html#accidental-constraints)

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

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