On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis <github.com+7693005+jarviscr...@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
