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

2020-05-26 Thread Mark Kralj-Taylor
/05/2020 05:59, David Holmes 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.openj

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

2020-05-07 Thread Mark Kralj-Taylor
cially if openjdk can be built on its minimum required per-platform OS version in a (Docker) container. Mark On Tue, 14 Apr 2020 at 23:34, David Holmes wrote: > > Hi Mark, > > On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote: > > David, Daniel, > > What is the oldest (lowe

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

2020-04-14 Thread Mark Kralj-Taylor
uire CLOCK_MONOTONIC - which would mean clock_gettime(CLOCK_REALTIME) is supported. Mark On Tue, 14 Apr 2020 at 18:04, Mark Kralj-Taylor wrote: > > Daniel, > Yes System.currentTimeMillis() and Clock.systemUTC() must be > consistent, so should use the same OS time source (as shown by

Re: os::javaTimeSystemUTC to call nanosecond precision OS API, so Clock.systemUTC() can give nanosecond precision UTC

2020-04-14 Thread Mark Kralj-Taylor
Daniel, Yes System.currentTimeMillis() and Clock.systemUTC() must be consistent, so should use the same OS time source (as shown by ). The patch to os_linux.cpp ensures this by calling the same Linux API: clock_gettime(CLOCK_REALTIME) for both, from: - os::javaTimeMillis() that backs