os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

Daniel Fuchs daniel.fuchs at oracle.com
Tue Apr 14 12:29:07 UTC 2020


On 11/04/2020 00:53, David Holmes wrote:
> Update:
>> It's a holiday weekend so I can't dig into this right now but we tried 
>> using a high-precision clock source for systemUTC() in the past but it 
>> didn't work because systemUTC() and currentTimeMillis() have to use 
>> the same time base, and currentTimeMillis() has to use gettimeofday(). 
>> I thought this cross-dependency was documented somewhere but can't 
>> find it right now. If gettimeofday and clock_gettime(CLOCK_REALTIME) 
>> actually have the same time characteristics wrt. wall-clock time then 
>> changing both as suggested may indeed work.

Just to emphasize David's comment: System::currentTimeMillis() and
Clock::systemUTC() should use the same time source: if they don't - then
some tests will fail, and because it can be tricky to assert things
in tests, they might (and probably will) fail only intermittently.

I'm probably the culprit here, I added those tests when I upgraded
Clock::systemUTC() to report sub millisecond granularity [1] - as was
available in the underlying clock that System::currentTimeMillis()
already used.

However, I think I would be disturbed if System::currentTimeMillis()
and Clock::systemUTC() were using different clocks and could
report a different notion of time (by drifting away from each other).

best regards,

-- daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8068730

More information about the hotspot-runtime-dev mailing list