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
best regards,
-- daniel
Because using it for high precision timestamps would only make sense if
it is similar lightweight.
Greetings
Bernd
Am Fri, 09 Jan 2015
17:56:28 +0100 schrieb Daniel Fuchs <daniel.fu...@oracle.com>:
Hi,
Please find below a webrev for:
8068730: Increase the precision of the implementation
of java.time.Clock.systemUTC()
https://bugs.openjdk.java.net/browse/JDK-8068730
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.
http://cr.openjdk.java.net/~dfuchs/webrev_8068730/webrev.00/
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
System.currentTimeMillis.
- fixes java.util.Formatter - which wasn't expecting
greater than millisecond precision.
testing:
- 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
