On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart <plev...@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@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
