On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis
wrote:
>>> 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 m
On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis
wrote:
>>> 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 m
On Wed, 10 Feb 2021 14:08:22 GMT, PROgrm_JARvis
wrote:
>>> 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 m
On Thu, 7 Jan 2021 17:09:14 GMT, Claes Redestad wrote:
>> 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 improvem
On Thu, 7 Jan 2021 16:39:48 GMT, Peter Levart 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
On Sun, 20 Dec 2020 22:41:33 GMT, PROgrm_JARvis
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
On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman 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 garb
On Sun, 20 Dec 2020 20:45:55 GMT, Claes Redestad 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
On Sun, 20 Dec 2020 19:48:43 GMT, Alan Bateman 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
On Fri, 18 Dec 2020 20:11:26 GMT, Stuart Marks 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 garb
On Fri, 18 Dec 2020 19:04:36 GMT, Sean Mullan wrote:
>>> MD5 and DES were removed as SE requirements in JDK 14. See
>>> https://bugs.openjdk.java.net/browse/JDK-8214483 for more information.
>>> However, there are no plans to remove the implementations from the JDK at
>>> this time.
>>
>> In
On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis
wrote:
> > MD5 and DES were removed as SE requirements in JDK 14. See
> > https://bugs.openjdk.java.net/browse/JDK-8214483 for more information.
> > However, there are no plans to remove the implementations from the JDK at
> > this time.
>
> In
On Fri, 18 Dec 2020 15:48:52 GMT, PROgrm_JARvis
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 t
> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to
> an internal holder class.
PROgrm_JARvis has updated the pull request incrementally with two additional
commits since the last revision:
- 8258588: add Md5MessageDigestLookup benchmark
- 8258588: make UUID#Md5Dige
On Fri, 18 Dec 2020 15:24:21 GMT, Claes Redestad 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
On Fri, 18 Dec 2020 14:59:10 GMT, PROgrm_JARvis
wrote:
>> A more general issue is that this patch assumes the `MessageDigest` object
>> returned is statically shareable, which implies it being stateless and
>> thread-safe.
>>
>> This doesn't seem to be the case. See
>> [MD5.java](https://git
On Fri, 18 Dec 2020 14:55:08 GMT, Claes Redestad wrote:
> A more general issue is that this patch assumes the `MessageDigest` object
> returned is statically shareable, which implies it being stateless and
> thread-safe.
>
> This doesn't seem to be the case. See
> [MD5.java](https://github.co
On Fri, 18 Dec 2020 14:42:38 GMT, PROgrm_JARvis
wrote:
>>> I've looked through [Standard Algorithms section for
>>> MessageDigest](https://docs.oracle.com/en/java/javase/15/docs/specs/security/standard-names.html#messagedigest-algorithms)
>>> and is says
>>>
>>> > Algorithm names that _can_ b
On Fri, 18 Dec 2020 14:37:53 GMT, Sean Mullan wrote:
> MD5 and DES were removed as SE requirements in JDK 14. See
> https://bugs.openjdk.java.net/browse/JDK-8214483 for more information.
> However, there are no plans to remove the implementations from the JDK at
> this time.
In this case, sho
On Fri, 18 Dec 2020 14:29:00 GMT, PROgrm_JARvis
wrote:
>> There are pre-existing microbenchmarks for java.security under
>> test/micro/org/openjdk/bench/java/security
>>
>> You can build and run these using `make test TEST=micro:YourBenchmark`.
>> Refer to
>> [doc/testing.md](https://github.
On Fri, 18 Dec 2020 14:01:19 GMT, Claes Redestad wrote:
> I'd suggest starting with a simple micro that zooms in on
> MessageDigest.getInstance("MD5"), maybe like so:
Thanks, that's what I wanted to hear.
I will implement it now.
-
PR: https://git.openjdk.java.net/jdk/pull/1821
On Fri, 18 Dec 2020 13:39:48 GMT, Alan Bateman wrote:
> Can you look in test/micro for existing examples?
Yes, of course, the question is more about the following: should I simply cover
`UUID#nameUUIDFromBytes(byte[])` by the benchmark or should I rather write a
comparison benchmark which woul
On Fri, 18 Dec 2020 13:39:48 GMT, Alan Bateman wrote:
>>> If there is a holder class for the MessageDigest then its initialisation
>>> can fail, this would allow the orThrow method to go away
>>
>> As of allowing `Md5Digest` instead of explicitly throwing the exception from
>> `orThrow` I thin
On Fri, 18 Dec 2020 13:27:02 GMT, PROgrm_JARvis
wrote:
>> Are you planning to add a microbenchmark to demonstrate the issue?
>> If there is a holder class for the MessageDigest then its initialisation can
>> fail, this would allow the orThrow method to go away
>
>> If there is a holder class fo
On Fri, 18 Dec 2020 09:10:26 GMT, Alan Bateman wrote:
> If there is a holder class for the MessageDigest then its initialisation can
> fail, this would allow the orThrow method to go away
As of allowing `Md5Digest` instead of explicitly throwing the exception from
`orThrow` I think that the la
On Thu, 17 Dec 2020 13:36:17 GMT, PROgrm_JARvis
wrote:
> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to
> an internal holder class.
Are you planning to add a microbenchmark to demonstrate the issue?
If there is a holder class for the MessageDigest then its initial
> Please review this change moving lookup of MD5 digest in `java.lang.UUID` to
> an internal holder class.
PROgrm_JARvis has updated the pull request incrementally with one additional
commit since the last revision:
8258588: add missing " UUIDs" to comment of UUID$Md5Digest
-
Ch
27 matches
Mail list logo
