RFR: 8258588: MD5 MessageDigest in java.util.UUID should be cached
PROgrm_JARvis
github.com+7693005+jarviscraft at openjdk.java.net
Fri Dec 18 16:04:18 UTC 2020
On Fri, 18 Dec 2020 15:48:52 GMT, PROgrm_JARvis <github.com+7693005+JarvisCraft at openjdk.org> wrote:
>> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner).
>
>> Might be fun to try, but it looks like rewriting to have MD5 to only use transient state will be a significant effort, and might just end up shuffling over allocations from `getInstance` to `digest`, which could regress code that reuse a digest instance (in a thread safe manner).
>
> I've thought about using `ThreadLocal` at holder level and my naive benchmark shows significant improvement in speed compared to current implementation: https://gist.github.com/JarvisCraft/61cd45f83aea7f33cba9510e523a5c4e
>
> As of the state from single thread's perspective, it seems to be safe to reuse `MessageDigest` in this case:
>
>> The `digest` method can be called once for a given number of updates. After `digest` has been called, the MessageDigest object is reset to its initialized state.
I've pushed the change utilizing `ThreadLocal` and my benchmark to correspond to the discussion.
-------------
PR: https://git.openjdk.java.net/jdk/pull/1821
More information about the security-dev
mailing list