Please review this change moving lookup of MD5 digest in `java.lang.UUID` to an
internal holder class.
-
Commit messages:
- 8258588: MD5 MessageDigest in java.util.UUID should be cached
Changes: https://git.openjdk.java.net/jdk/pull/1821/files
Webrev: https://webrevs.openjdk.java.
> 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 o
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 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 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 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: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 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
> 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: mak
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 coul
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 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 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
This is trivial fix of
[JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
which replaces manually-computed `int`-based `long` hash-code.
Because `Long#hashCode(long)` uses other hashing function than the one
currently used here:
https://github.com/openjdk/jdk/blob/
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashin
On Mon, 4 Oct 2021 21:13:02 GMT, PROgrm_JARvis wrote:
> This is trivial fix of
> [JDK-8274686](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8274686)
> which replaces manually-computed `int`-based `long` hash-code.
>
> Because `Long#hashCode(long)` uses other hashin
t available to code (e.g. as a `public static
final` constant) so that other code in JDK (like this PR) and foreign code can
rely on it?
For example, I have to duplicate this value based on Javadoc
[here](https://github.com/JarvisCraft/padla/blob/118c89e078cfc8e54faf154f2f4e658604159ab0/ultimate-m
On Sat, 20 Nov 2021 04:40:22 GMT, Stuart Marks wrote:
> Regarding the slot limit in `StringConcatFactory`, it's not clear to me the
> limit of 200 is normative or is merely an implementation note. The limit of
> 200 slots seems to be arbitrary and shouldn't be baked into the spec. Perhaps
> th
This is a trivial fix to make `String(String)` constructor copy the value of
`hashIsZero` field.
-
Commit messages:
- fix: copy `hashIsZero` in `String#String(String)`
Changes: https://git.openjdk.java.net/jdk/pull/6511/files
Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6
On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote:
> This is a trivial fix to make `String(String)` constructor copy the value of
> `hashIsZero` field.
Hi there, could anyone please sponsor this change if it is still applicable?
Thanks in advance!
-
PR:
On Mon, 22 Nov 2021 22:59:21 GMT, PROgrm_JARvis wrote:
> This is a trivial fix to make `String(String)` constructor copy the value of
> `hashIsZero` field.
This pull request has now been integrated.
Changeset: e30e6767
Author:Petr Portnov
Committer: Roger Riggs
URL:
On Wed, 23 Feb 2022 22:33:42 GMT, liach wrote:
> Replaces simple `for (Map.Entry entry : map.entrySet())` with
> `map.forEach((k, v) ->)` calls. This change is better for thread-safety and
> reduces allocation for some map implementations.
>
> A more in-depth description of benefits is availab
22 matches
Mail list logo
