On Tue, 20 May 2025 19:37:31 GMT, Philippe Marschall <d...@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
