RFR 8068730: Increase the precision of the implementation of java.time.Clock.systemUTC()

[Daniel Fuchs]

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.fuchs at 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
>