RFR: 8334015: Add Support for UUID Version 7 (UUIDv7) defined in RFC 9562 [v3]

[kieran-farrell]

On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall <duke at openjdk.org> 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