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
Hi,
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