RFR(S) 8242504: Enhance the system clock to nanosecond precision

[David Holmes]

On 26/05/2020 6:14 pm, Stephen Colebourne wrote:
> AFAICT a nanosecond clock is fine from a java.time.* API perspective.

Thanks Stephen. Is this a review or just a nod of approval? :)

Cheers,
David
-----

> Stephen
> 
> On Tue, 26 May 2020 at 06:01, David Holmes <david.holmes at oracle.com> wrote:
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8242504
>> webrev: http://cr.openjdk.java.net/~dholmes/8242504/webrev/
>>
>> This work was contributed by Mark Kralj-Taylor:
>>
>> https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-April/038975.html
>>
>> On the hotspot side we change the Linux implementations of
>> javaTimeMillis() and javaTimeSystemUTC() so that they use
>> clock_gettime(CLOCK_REALTIME) instead of gettimeofday(). In keeping with
>> our conditional use of this API I added a new guard
>>
>> os::Posix::supports_clock_gettime()
>>
>> and refined the existing supports_monotonic_clock() so that we can still
>> use CLOCK_REALTIME if CLOCK_MONOTONIC does not exist. In the future
>> (hopefully very near future) we will simply assume these APIs always exist.
>>
>> On the core-libs side the existing test:
>>
>> test/jdk/java/time/test/java/time/TestClock_System.java
>>
>> is adjusted to track the precision in more detail.
>>
>> Finally Mark has added instantNowAsEpochNanos() to the benchmark
>> previously known as
>>
>> test/micro/org/openjdk/bench/java/lang/Systems.java
>>
>> which I've renamed to SystemTime.java as Mark suggested. I agree having
>> these three functions measured together makes sense.
>>
>> Testing:
>>     - test/jdk/java/time/test/java/time/TestClock_System.java
>>     - test/micro/org/openjdk/bench/java/lang/SystemTime.java
>>     - Tiers 1-3
>>
>> Thanks,
>> David