I'm not an official OpenJDK reviewer, nor would I be confident reviewing the native code here. Stephen
On Tue, 26 May 2020 at 14:28, David Holmes <david.hol...@oracle.com> wrote: > > 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.hol...@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
