On Mon, 19 May 2025 13:33:51 GMT, kieran-farrell <d...@openjdk.org> 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 > 10000 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. 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. 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? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096254869 PR Review Comment: https://git.openjdk.org/jdk/pull/25303#discussion_r2096265946
