RFR 8068730: Increase the precision of the implementation of java.time.Clock.systemUTC()
daniel.fuchs at oracle.com
Fri Jan 9 17:46:45 UTC 2015
On 09/01/15 18:25, Bernd Eckenfels wrote:
> Hello Daniel,
> this is good news. I do wonder: is there a plan to make this an
> intrinsic(+vsyscall on Linux) just like System.currentTimeMillis()?
I guess it is a possibility if there is a need, but not in this
changeset, and not by me, as I wouldn't know where to start ;-)
For the record I have done some microbenchmarking and the performance
of the new implementation does not seem to be very far from the old.
I have compared Instant.ofEpochMilli(System.currentTimeMillis())
with systemUTC.instant() on my machine:
t.j.t.ClockBenchmark.testInstantOfEpochMillis thrpt 40
22610258.156 ± 209829.169 ops/s
t.j.t.ClockBenchmark.testSystemUTC thrpt 40
18569691.759 ± 160916.846 ops/s
> Because using it for high precision timestamps would only make sense if
> it is similar lightweight.
> Am Fri, 09 Jan 2015
> 17:56:28 +0100 schrieb Daniel Fuchs <daniel.fuchs at oracle.com>:
>> Please find below a webrev for:
>> 8068730: Increase the precision of the implementation
>> of java.time.Clock.systemUTC()
>> The java.time.Clock.system() method (and variants thereof) are
>> specified to "obtain a clock that returns the current instant
>> using best available system clock". However the current
>> implementation of the clock returned is based on
>> System.currentTimeMillis() whereas the underlying native clock
>> used by System.currentTimeMillis() has often a greater precision
>> than milliseconds (for instance, on Linux, System.currentTimeMillis()
>> is based on gettimeofday, which offers microseconds precision).
>> This patch enhances the implementation of the
>> java.time.Clock.SystemClock, so that it offer at least the
>> same precision than the underlying clock available on the system.
>> There is no change in the public API.
>> Some more details on the patch:
>> native (hotspot) side:
>> - adds a new method to the os class:
>> os::javaTimeSystemUTC(jlong &seconds, jlong &nanos)
>> which allows to get the time in the form of a number
>> of seconds and number of nanoseconds
>> (see os.hpp and various os_<os>.cpp files)
>> - adds a JVM_GetNanoTimeAdjustment method, which takes
>> an offset (in seconds) as parameter and returns a
>> nano time adjustment compared to the offset.
>> Calls os::javaTimeSystemUTC to compute the adjustment
>> (see jvm.cpp)
>> java (jdk) side:
>> - adds a native sun.misc.VM.getNanoTimeAdjustment method
>> (which is bound to JVM_GetNanoTimeAdjustment)
>> (see VM.java and VM.c)
>> - modifies java.time.Clock.SystemClock to call the new
>> sun.misc.VM.getNanoTimeAdjustment instead of
>> - fixes java.util.Formatter - which wasn't expecting
>> greater than millisecond precision.
>> - A new test is added to test sun.misc.VM.getNanoTimeAdjustment
>> In particular it checks the edge cases.
>> - New tests are added to TestClock_System.java to check for
>> the increased precision.
>> There is also a test for the edge cases there.
>> - Some java.time tests where tripped by the increased precision,
>> and had to be modified to take that into account
>> Note: comparing the new os::javaTimeSystemUTC with os::javaTimeMillis
>> can help in reviewing the changes.
>> best regards,
>> -- daniel
More information about the hotspot-runtime-dev