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

[Peter Levart]

On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft 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?
>> 
>> This is a good point. Significant effort has gone into recent releases to reduce the use of TLs in the (JDK-8245309, JDK-8245308, JDK-8245304, JDK-8245302) so adding new usages is a disappointing. So I think this PR does need good justifications, and probably a lot more exploration of options.
>
>> 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

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

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