Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: update RFC - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/b0b4f7a8..922869b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00-01 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2]
On Mon, 19 May 2025 18:08:18 GMT, Roger Riggs wrote:
>> kieran-farrell has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> update RFC
>
> src/java.base/share/classes/java/util/UUID.java line 195:
>
>> 193: *
>> 194: * @return A {@code UUID} generated from the current system time
>> 195: */
>
> Seems like there should be a reference to the RFC somewhere here using the
> @spec javadoc tag.
>
> And also in the class javadoc.
spec updated in class javadoc to RFC 9562 which obsolete RFC 4122, @spec tag
also added above the method.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097772811
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2]
On Mon, 19 May 2025 18:17:09 GMT, Roger Riggs wrote: > Can the sub-microsecond value just be truncated and avoid the expensive > divide operation?' method 3 of secion 6.2 of https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters states > start with the portion of the timestamp expressed as a fraction of the > clock's tick value (fraction of a millisecond for UUIDv7). Compute the count > of possible values that can be represented in the available bit space, 4096 > for the UUIDv7 rand_a field. Using floating point or scaled integer > arithmetic, multiply this fraction of a millisecond value by 4096 and round > down (toward zero) to an integer result to arrive at a number between 0 and > the maximum allowed for the indicated bits, which sorts monotonically based > on time. ' so i think we might have to keep the division? though i re-shuffled the equation to `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);` which gives scaled integer division rather than floating point and gave a very slight imporved perfomance to 143.758 ± 2.135 ns/op - PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2097994819
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v2]
On Tue, 20 May 2025 13:35:32 GMT, kieran-farrell wrote:
>> src/java.base/share/classes/java/util/UUID.java line 219:
>>
>>> 217: randomBytes[8] |= (byte) 0x80;
>>> 218:
>>> 219: return new UUID(randomBytes);
>>
>> This could remove the allocation by composing the high and low longs using
>> shifts and binary operations and ng.next().
>> Can the sub-microsecond value just be truncated and avoid the expensive
>> divide operation?
>
>> Can the sub-microsecond value just be truncated and avoid the expensive
>> divide operation?'
>
> method 3 of secion 6.2 of
> https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters
> states
>
>> start with the portion of the timestamp expressed as a fraction of the
>> clock's tick value (fraction of a millisecond for UUIDv7). Compute the count
>> of possible values that can be represented in the available bit space, 4096
>> for the UUIDv7 rand_a field. Using floating point or scaled integer
>> arithmetic, multiply this fraction of a millisecond value by 4096 and round
>> down (toward zero) to an integer result to arrive at a number between 0 and
>> the maximum allowed for the indicated bits, which sorts monotonically based
>> on time. '
>
> so i think we might have to keep the division? though i re-shuffled the
> equation to
>
> `int nsBits = (int) ((nsTime % 1_000_000) / 1_000_000.0 * 4096);`
>
> which gives scaled integer division rather than floating point and gave a
> very slight imporved perfomance to 143.758 ± 2.135 ns/op
> This could remove the allocation by composing the high and low longs using
> shifts and binary operations and ng.next().
do you mean to create the UUID using most and least significant bytes? if so,
I've tried out some variations, i found creating the 64 bit lsb with
ng.nextLong() brings a large pefomance decrease over using the nextBytes
method, but the below implemntation keeping with the nextByte(byte[]) api
brings a performance increase to 121.128 ± 30.486 ns/op, though the code might
appear a little roundabout.
public static UUID timestampUUID() {
long msTime = System.currentTimeMillis();
long nsTime = System.nanoTime();
// Scale sub-ms nanoseconds to a 12-bit value
int nsBits = (int) ((nsTime % 1_000_000L) * 4096L / 1_000_000L);
// Compose the 64 most significant bits: [48-bit msTime | 4-bit version
| 12-bit nsBits]
long mostSigBits =
((msTime & 0xL) << 16) |
(0x7L << 12) |
nsBits;
// Generate 8 random bytes for least significant bits
byte[] randomBytes = new byte[8];
SecureRandom ng = UUID.Holder.numberGenerator;
ng.nextBytes(randomBytes);
long leastSigBits = 0;
for (int i = 0; i < 8; i++) {
leastSigBits = (leastSigBits << 8) | (randomBytes[i] & 0xFF);
}
// Set variant (bits 62–63) to '10'
leastSigBits &= 0x3FFFL;
leastSigBits |= 0x8000L;
return new UUID(mostSigBits, leastSigBits);
}
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2098044396
RFR: 8347027: String replaceAll with Function
New API to the String.java class - replaceAllMapped(String, Function) that allows regex based replacement via a user defined function allowing dynamic replacemnt based on the match. It delegates to the already existing Pattern.matcher().replaceAll(Function). - Commit messages: - whitespace - updates - replaceAllMapped and test Changes: https://git.openjdk.org/jdk/pull/25335/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25335&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347027 Stats: 61 lines in 3 files changed: 61 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25335.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25335/head:pull/25335 PR: https://git.openjdk.org/jdk/pull/25335
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: Update src/java.base/share/classes/java/util/UUID.java Co-authored-by: Andrey Turbanov - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/922869b3..c7efd528 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562
With the recent approval of UUIDv7 (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static method UUID.timestampUUID() which constructs and returns a UUID in support of the new time generated UUID version. The specification requires embedding the current timestamp in milliseconds into the first bits 0–47. The version number in bits 48–51, bits 52–63 are available for sub-millisecond precision or for pseudorandom data. The variant is set in bits 64–65. The remaining bits 66–127 are free to use for more pseudorandom data or to employ a counter based approach for increased time percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). The choice of implementation comes down to balancing the sensitivity level of being able to distingush UUIDs created below <1ms apart with performance. A test simulating a high-concurrency environment with 4 threads generating 1 UUIDv7 values in parallel to measure the collision rate of each implementation (the amount of times the time based portion of the UUID was not unique and entries could not distinguished by time) yeilded the following results for each implemtation: - random-byte-only - 99.8% - higher-precision - 3.5% - counter-based - 0% Performance tests show a decrease in performance as expected with the counter based implementation due to the introduction of synchronization: - random-byte-only 143.487 ± 10.932 ns/op - higher-precision 149.651 ± 8.438 ns/op - counter-based 245.036 ± 2.943 ns/op The best balance here might be to employ a higher-precision implementation as the large increase in time sensitivity comes at a very slight performance cost. - Commit messages: - update to add ns percision - 3 variantions - UUID src and test Changes: https://git.openjdk.org/jdk/pull/25303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334015 Stats: 108 lines in 2 files changed: 104 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Withdrawn: 8347027: String replaceAll with Function
On Tue, 20 May 2025 16:59:10 GMT, kieran-farrell wrote: > New API to the String.java class - replaceAllMapped(String, > Function) that allows regex based replacement via a user > defined function allowing dynamic replacemnt based on the match. It delegates > to the already existing Pattern.matcher().replaceAll(Function). This pull request has been closed without being integrated. - PR: https://git.openjdk.org/jdk/pull/25335
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3]
On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall wrote: >> There's no (time-based) relationship between the currentTimeMillis() value >> and the nanoTime value. >> They are independent clocks and are read separately and are un-correlated. >> They won't be usable as lsb of the millis value. >> >> I'm surprised that the `nextBytes` is slower, since it looks like it calls >> `nextLong` and puts it in a newly allocated byte[8]. Normal perf >> measurements won't account for the gc overhead to recover it. >> >> The nsBits computation looks odd, nanoTme returns nanoseconds (10^9), the >> remainder (% 1_000_000) is then milliseconds. > >> if so, I've tried out some variations, i found creating the 64 bit lsb with >> ng.nextLong() brings a large pefomance decrease over using the nextBytes >> method > > Probably because `SecureRandom` gets `#nextLong()` from `Random`, which ends > up calling `#next(int)` twice, so it allocates twice. Overriding > `#nextLong()` in `SecureRandom` may help a little but will still have to > allocate as long as `SecureRandomSpi` is not updated. The nsBytes were included to give some additional but not guaranteed monotonicity in the event of msTime collisions on a single instance of a JVM. I updated the method to print the msTime and nsBits for visual purposes seen below. The nsBits increase until cycling back to a lower value on the last or +/- 1 of the last instance of the same msTime value as tested on Linux and MacOS . I'm not sure of the reason why the cycles are almost in sync given that the times are not linked. However Marschall has pointed out that nanoTime() resolution is weaker on windows so maybe its not something that can be depended on. In that case I could revert to the random byte only implementation and remove the nsBytes fro random data. As for the nsBits computation, in order to align with the RFC, my understanding was to get the remainder of nsTime (% 1_000_000) to get the nanoseconds within the current millisecond, divide by 1_000_000 to convert to a fraction of a ms and multiply by 4096L to scale to the integer range to fit into the 12 bits permitted for the ns timestamp. msTime: 1747835228108, nsBits: 1336 msTime: 1747835228137, nsBits: 1333 msTime: 1747835228137, nsBits: 1794 msTime: 1747835228137, nsBits: 2206 msTime: 1747835228137, nsBits: 2766 msTime: 1747835228137, nsBits: 3040 msTime: 1747835228137, nsBits: 3485 msTime: 1747835228137, nsBits: 3901 msTime: 1747835228138, nsBits: 239 msTime: 1747835228138, nsBits: 651 msTime: 1747835228138, nsBits: 918 msTime: 1747835228138, nsBits: 1321 msTime: 1747835228138, nsBits: 1729 msTime: 1747835228138, nsBits: 2140 msTime: 1747835228138, nsBits: 2535 msTime: 1747835228138, nsBits: 2874 msTime: 1747835228138, nsBits: 3243 msTime: 1747835228138, nsBits: 3641 msTime: 1747835228138, nsBits: 3967 msTime: 1747835228139, nsBits: 227 msTime: 1747835228139, nsBits: 524 - PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2100405267
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3]
On Wed, 28 May 2025 20:57:15 GMT, Roger Riggs wrote: >> The first 48 bits need to be from the unix epoch time stamp in ms only to >> remain complaint. If I understand correctly, to be able to guarantee that >> the nsBits are actually time orderable, System.nanoTime() would have to be >> pinned to a point where System.currentTimeMillis() increments by 1ms (which >> doesnt seem possible). Otherwise any offset could be at any arbitrary point >> in a given millisecond and nsBits would wrap around from that. >> >> I think the options are to either use the random only approach with ms >> precision or an guaranteed monotonic counter based approach and take the hit >> on performance. >> >> I agree with updating to "create" from "retrieve" on the first line comment >> and also with the method name change to avoid confusion with UUIDv1, however >> to either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise >> depending on which implementation we settle on. > > We don't have a reliable sub-microsecond source across platforms, so can only > be confident using random numbers for the low order bits. (and I don't expect > a higher resolution monotonic clock to be available anytime soon). > > Would the static factory method be more useful if it took the mstime as a > parameter? > That would allow the caller to pick the time source. For example, > `UUID ts = UUID.timesteampUUID(System.currentTimeMillis());` > It would avoid locking into the System.currentTimeMillis() and allows the > application to create UUIDs for whatever time meets its needs. > > Adding a unixEpochTimeMillis() makes sense, re-assembling the time bits into > the ms time. In terms of using another clock it could open up possiblities of passing non complaint time formats to the method, but maybe thats something that could be mostly prevented with input validation and clear documentation i.e. “timestamp must be Unix time in milliseconds.” As far as I know all other standard Java methods that gives the current time in milliseconds ultimately delegates to System.currentTimeMillis(). Maybe there would be a use case in generating UUIDs by passing compliant timestamps for entries created in the past, like updating a database to use UUIDv7? - PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2114384770
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v5]
On Sun, 8 Jun 2025 16:15:40 GMT, Kieran Farrell wrote:
>> With the recent approval of UUIDv7
>> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new
>> static method UUID.timestampUUID() which constructs and returns a UUID in
>> support of the new time generated UUID version.
>>
>> The specification requires embedding the current timestamp in milliseconds
>> into the first bits 0–47. The version number in bits 48–51, bits 52–63 are
>> available for sub-millisecond precision or for pseudorandom data. The
>> variant is set in bits 64–65. The remaining bits 66–127 are free to use for
>> more pseudorandom data or to employ a counter based approach for increased
>> time percision
>> (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7).
>>
>> The choice of implementation comes down to balancing the sensitivity level
>> of being able to distingush UUIDs created below <1ms apart with performance.
>> A test simulating a high-concurrency environment with 4 threads generating
>> 1 UUIDv7 values in parallel to measure the collision rate of each
>> implementation (the amount of times the time based portion of the UUID was
>> not unique and entries could not distinguished by time) yeilded the
>> following results for each implemtation:
>>
>>
>> - random-byte-only - 99.8%
>> - higher-precision - 3.5%
>> - counter-based - 0%
>>
>>
>> Performance tests show a decrease in performance as expected with the
>> counter based implementation due to the introduction of synchronization:
>>
>> - random-byte-only 143.487 ± 10.932 ns/op
>> - higher-precision 149.651 ± 8.438 ns/op
>> - counter-based 245.036 ± 2.943 ns/op
>>
>> The best balance here might be to employ a higher-precision implementation
>> as the large increase in time sensitivity comes at a very slight performance
>> cost.
>
> Kieran Farrell has updated the pull request incrementally with one additional
> commit since the last revision:
>
> updates
@BsoBird
The RFC states that 'Implementations SHOULD utilize a cryptographically secure
pseudorandom number generator (CSPRNG) to provide values that are both
difficult to predict ("unguessable") and have a low likelihood of collision
("unique")."
That implementation uses ThreadLocalRandom which does not generate
cryptographically secure randomness. For improved security and uniqueness of
UUIDs, it might be better to use SecureRandom, also aligning with the behavoir
of the randomUUID() method.
-
PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3001419924
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v6]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update unixEpochTimeMillis() spec update - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/804187fd..aefc4a84 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v7]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - rebase - updates - update test - update test - updates - update method to lsb and msb with arraybytes - Update src/java.base/share/classes/java/util/UUID.java Co-authored-by: Andrey Turbanov - update RFC - update to add ns percision - 3 variantions - ... and 1 more: https://git.openjdk.org/jdk/compare/984d7f9c...6c9255f6 - Changes: https://git.openjdk.org/jdk/pull/25303/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=06 Stats: 172 lines in 2 files changed: 166 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v4]
On Thu, 29 May 2025 18:30:59 GMT, Roger Riggs wrote: >> In terms of using another clock it could open up possiblities of passing non >> complaint time formats to the method, but maybe thats something that could >> be mostly prevented with input validation and clear documentation i.e. >> “timestamp must be Unix time in milliseconds.” As far as I know all other >> standard Java methods that gives the current time in milliseconds ultimately >> delegates to System.currentTimeMillis(). >> >> Maybe there would be a use case in generating UUIDs by passing compliant >> timestamps for entries created in the past, like updating a database to use >> UUIDv7? > > RFC 9562 does not indicate any relation between the timestamp value and the > "current" time. > So yes, document it as the Unix Epoch, milliseconds since 1970. > There could be plenty of use cases for creating a UUID from some other source > of time, like the timestamp of a file or a time field in a database. Latest update: - changed to millis + randomByte allocation implementation - updated method to take user provided timestamp - added API which delegates to method with current timestamp if no user input provided - validated user input (this is far from fool proof, but prevents negative time values and some other time formats) - updated method name to unixEpochTimeMillis - added a note with ref to rfc to make user aware of time format required for rfc compliance - added test coverage Updated benchmark: Benchmark Mode CntScoreError Units UUIDBenchmark.unixEpochTimeMillis avgt 25 138.076 ± 11.438 ns/op - PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2115691663
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v4]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. kieran-farrell has updated the pull request incrementally with four additional commits since the last revision: - update test - update test - updates - update method to lsb and msb with arraybytes - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/c7efd528..33d8ccbf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=02-03 Stats: 80 lines in 2 files changed: 51 ins; 4 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3]
On Tue, 27 May 2025 21:59:55 GMT, Roger Riggs wrote:
>> I'd say "create" instead of "retrieve" in the first line comment. (Though
>> that word is used in the other static factories).
>>
>> The "sub-millisecond precision" can't be relied upon. Its the precision that
>> gives the impression that it can be added to the millisecond value and get
>> an exact time. But the nano-second value is read from a different clock and
>> the bits being used from it may wrap-around in the time between the reads of
>> the clocks.
>> The second description ("derived from") is makes fewer promises than the
>> first-line comment.
>> An application should not use them for any purpose other than random. And
>> for that the buffer already contains random bytes.
>>
>> An alternative is to capture the MS time and the nano-time on first use to
>> compute an offset and then use only the nano-time plus/minus the offset to
>> create the version 7 UUIDs.
>
> The `timestamp` method may mislead an app developer thinking its the time
> from the version 7 timestamp.
> The first-line comment might make it more obvious if it says:
> `The timestamp value associated with a version 1 UUID.`
>
> The Unix Epoch time would be easier to use if a method was added to return it.
> `long UnixEpochTimeNanos()` (name subject to bike-shedding).
> And throwing if it was not version 7.
The first 48 bits need to be from the unix epoch time stamp in ms only to
remain complaint. If I understand correctly, to be able to guarantee that the
nsBits are actually time orderable, System.nanoTime() would have to be pinned
to a point where System.currentTimeMillis() increments by 1ms (which doesnt
seem possible). Otherwise any offset could be at any arbitrary point in a given
millisecond and nsBits would wrap around from that.
I think the options are to either use the random only approach with ms
precision or an guaranteed monotonic counter based approach and take the hit on
performance.
I agree with updating to "create" from "retrieve" on the first line comment and
also with the method name change to avoid confusion with UUIDv1, however to
either unixEpochTimeNanos() or unixEpochTimeMillis() or otherwise depending on
which implementation we settle on.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2112383140
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v5]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. kieran-farrell has updated the pull request incrementally with one additional commit since the last revision: updates - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/33d8ccbf..804187fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=03-04 Stats: 15 lines in 1 file changed: 12 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v13]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update note to @api note - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/a72f1834..be7dea7a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=11-12 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12]
On Thu, 3 Jul 2025 07:03:19 GMT, Alan Bateman wrote:
>> Kieran Farrell has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> rm whitespace
>
> src/java.base/share/classes/java/util/UUID.java line 212:
>
>> 210: * @since 26
>> 211: */
>> 212: public static UUID unixEpochTimeMillis() {
>
> Is there a list anywhere on the names that have been discussed already?
> Asking because the existing static factory method for a type 4 is
> randomUUID(). Also, there are several methods (esp. in java.time) that use
> "Epoch" in method names name rather than "Unix Epoch". Also if you rename the
> timestamp parameter to something that includes "millis" in the name then it
> would help usage in IDEs where it's more obvious at the use-site that the
> parameter is in millis.
The original proposed name was `timestampUUID` but it was decided against to
avoid confusion with UUID-v1, which is also time-based, there hasnt been much
discussion beyond that. Maybe something like `epochMilliUUID()` would better
follow the naming conventions?
Reagarding the parameter, updating to something like `epochMillis` or
`timestampMillis` would make sense.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2182365873
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]
On Wed, 2 Jul 2025 09:52:54 GMT, Raffaello Giulietti wrote: >> Hello Roger, that's true about the uniqueness semantics. However, from what >> I understand of RFC-9562, on which this new API is based, I think it has >> much stricter expectations about monotonocity (the first 48 bits) too. For >> example, the following sections: >> >> https://www.rfc-editor.org/rfc/rfc9562.html#name-timestamp-considerations >> https://www.rfc-editor.org/rfc/rfc9562.html#name-monotonicity-and-counters > > Indeed, the sections of the RFC mentioned by @jaikiran do require timestamps > to be (strictly) monotonic. The method `monotonicMS()` does not fulfill this > requirement. There are some methods described in §6.2 to help ensuring > monotonicity. > > While it is true that the 74 bits of randomness help in creating unique ID > with high probability, the requirements for the timestamp part in UUID > Version 7 seem more restrictive than just uniqueness. Hi Jaikiran, You are correct in that the current implementation only supports uniqueness among time clashes and not monotonicity. Although section 5.7 UUID version 7 states that adding monotonic or extra precision bits is optional and that the millisecond portion along with the random bits is sufficient, section 6.2 does state: > Take care to ensure UUIDs generated in batches are also monotonic. That is, > if one thousand UUIDs are generated for the same timestamp, there should be > sufficient logic for organizing the creation order of those one thousand > UUIDs The use of 'should' here makes it seem like this is a strong recommendation rather than a mandate. Regardless, it might be benifical to better satisfy this guidance. Since we don't currently have access to higher precision time, updating the implementation to include a dedicated counter would be the only viable approach, and comes at the cost of performance. - PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2179666440
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v12]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: rm whitespace - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/c06474fc..a72f1834 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=10-11 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]
On Mon, 30 Jun 2025 18:19:30 GMT, Kieran Farrell wrote: >> With the recent approval of UUIDv7 >> (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new >> static method UUID.timestampUUID() which constructs and returns a UUID in >> support of the new time generated UUID version. >> >> The specification requires embedding the current timestamp in milliseconds >> into the first bits 0–47. The version number in bits 48–51, bits 52–63 are >> available for sub-millisecond precision or for pseudorandom data. The >> variant is set in bits 64–65. The remaining bits 66–127 are free to use for >> more pseudorandom data or to employ a counter based approach for increased >> time percision >> (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). >> >> The choice of implementation comes down to balancing the sensitivity level >> of being able to distingush UUIDs created below <1ms apart with performance. >> A test simulating a high-concurrency environment with 4 threads generating >> 1 UUIDv7 values in parallel to measure the collision rate of each >> implementation (the amount of times the time based portion of the UUID was >> not unique and entries could not distinguished by time) yeilded the >> following results for each implemtation: >> >> >> - random-byte-only - 99.8% >> - higher-precision - 3.5% >> - counter-based - 0% >> >> >> Performance tests show a decrease in performance as expected with the >> counter based implementation due to the introduction of synchronization: >> >> - random-byte-only 143.487 ± 10.932 ns/op >> - higher-precision 149.651 ± 8.438 ns/op >> - counter-based 245.036 ± 2.943 ns/op >> >> The best balance here might be to employ a higher-precision implementation >> as the large increase in time sensitivity comes at a very slight performance >> cost. > > Kieran Farrell has refreshed the contents of this pull request, and previous > commits have been removed. The incremental views will show differences > compared to the previous content of the PR. The pull request contains one new > commit since the last revision: > > update spec One minor update made to include URL with spec tag as required + * @spec https://www.rfc-editor.org/rfc/rfc9562.html + * RFC 9562 Universally Unique IDentifiers (UUIDs) CSR body and fix version updated also. Many thanks @RogerRiggs. - PR Comment: https://git.openjdk.org/jdk/pull/25303#issuecomment-3020348465
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v9]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with 117 additional commits since the last revision: - url with spec tag - 8360867: CTW: Disable inline cache verification Reviewed-by: kvn, thartmann - 8274051: Remove supports_vtime()/elapsedVTime() Reviewed-by: kbarrett, iwalulya - 8361032: Problem list TestOnSpinWaitAArch64 until JDK-8360936 is fixed Reviewed-by: alanb - 8330940: Impossible to create a socket backlog greater than 200 on Windows 8+ Reviewed-by: michaelm, dfuchs, alanb - 8359266: Delete the usage of AppContext in the GraphicsDevice Reviewed-by: aivanov, azvegint - 8360478: libjsig related tier3 jtreg tests fail when asan is configured Reviewed-by: dholmes, ihse - 8359596: Behavior change when both -Xlint:options and -Xlint:-options flags are given Reviewed-by: mcimadamore, uschindler - 8360312: Serviceability Agent tests fail with JFR enabled due to unknown thread type JfrRecorderThread Reviewed-by: sspitsyn, kevinw, dholmes - 8359761: JDK 25 RDP1 L10n resource files update Reviewed-by: aivanov, almatvee, nbenalla, jlu, dnguyen, cstein, naoto - ... and 107 more: https://git.openjdk.org/jdk/compare/adb50724...1011035f - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/adb50724..1011035f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=07-08 Stats: 14624 lines in 651 files changed: 6244 ins; 5186 del; 3194 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v10]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: update spec - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/1011035f..1e730c24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=08-09 Stats: 14617 lines in 650 files changed: 5183 ins; 6239 del; 3195 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v11]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: spec updates - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/1e730c24..c06474fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=09-10 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
Re: RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v8]
> With the recent approval of UUIDv7 > (https://datatracker.ietf.org/doc/rfc9562/), this PR aims to add a new static > method UUID.timestampUUID() which constructs and returns a UUID in support of > the new time generated UUID version. > > The specification requires embedding the current timestamp in milliseconds > into the first bits 0–47. The version number in bits 48–51, bits 52–63 are > available for sub-millisecond precision or for pseudorandom data. The variant > is set in bits 64–65. The remaining bits 66–127 are free to use for more > pseudorandom data or to employ a counter based approach for increased time > percision (https://www.rfc-editor.org/rfc/rfc9562.html#name-uuid-version-7). > > The choice of implementation comes down to balancing the sensitivity level of > being able to distingush UUIDs created below <1ms apart with performance. A > test simulating a high-concurrency environment with 4 threads generating > 1 UUIDv7 values in parallel to measure the collision rate of each > implementation (the amount of times the time based portion of the UUID was > not unique and entries could not distinguished by time) yeilded the following > results for each implemtation: > > > - random-byte-only - 99.8% > - higher-precision - 3.5% > - counter-based - 0% > > > Performance tests show a decrease in performance as expected with the counter > based implementation due to the introduction of synchronization: > > - random-byte-only 143.487 ± 10.932 ns/op > - higher-precision 149.651 ± 8.438 ns/op > - counter-based 245.036 ± 2.943 ns/op > > The best balance here might be to employ a higher-precision implementation as > the large increase in time sensitivity comes at a very slight performance > cost. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: unroll loop - Changes: - all: https://git.openjdk.org/jdk/pull/25303/files - new: https://git.openjdk.org/jdk/pull/25303/files/6c9255f6..adb50724 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25303&range=06-07 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25303.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25303/head:pull/25303 PR: https://git.openjdk.org/jdk/pull/25303
