Hi David,
So the issue is that while glibc 2.12 (in OEL6.4) supports
clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on
librt.so, which is an optional runtime dependency, hence the dynamic
lookup you mention. The complexity of dynamic lookup makes this
enhancement unattractive. But
Hi Mark,
On 6/05/2020 1:50 am, Mark Kralj-Taylor wrote:
Hi David,
So the issue is that while glibc 2.12 (in OEL6.4) supports
clock_gettime(CLOCK_REALTIME) it requires a runtime dependency on
librt.so, which is an optional runtime dependency, hence the dynamic
lookup you mention. The complexity
* Florian Weimer:
> * Mark Kralj-Taylor:
>
>> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
>> should be supported if the clock_gettime() API exists. But other clock
>> sources are not mandatory.
>
> Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
> gettimeof
Hi Mark,
On 15/04/2020 3:09 am, Mark Kralj-Taylor wrote:
David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?
I'm not clear on that.
The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the decidi
David, Daniel,
What is the oldest (lowest) version of Linux and glibc for openjdk 15?
The availability of clock_gettime(CLOCK_REALTIME) on the oldest
Linux/glibc supported by openjdk 15 is likely to be the deciding
factor on if Hotspot Linux code can call
clock_gettime(CLOCK_REALTIME).
doc/buildi
* Mark Kralj-Taylor:
> The wording of Linux docs suggests that clock_gettime(CLOCK_REALTIME)
> should be supported if the clock_gettime() API exists. But other clock
> sources are not mandatory.
Really old glibc emulates clock_gettime (CLOCK_REALTIME) using
gettimeofday, yes.
clock_gettime was a
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 System.curren
Hi,
On 11/04/2020 00:53, David Holmes wrote:
Update:
It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and currentTimeMillis() have to use
the same time base, and curren
Update:
On 11/04/2020 9:45 am, David Holmes wrote:
Hi Mark,
Thanks for the very detailed proposal and write up!
It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and cu
Hi Mark,
Thanks for the very detailed proposal and write up!
It's a holiday weekend so I can't dig into this right now but we tried
using a high-precision clock source for systemUTC() in the past but it
didn't work because systemUTC() and currentTimeMillis() have to use the
same time base, an
Hi,
Created an entry to track the enhancement:
https://bugs.openjdk.java.net/browse/JDK-8242504
Changes affecting the Core Libraries APIs also need be reviewed by
core-libs-dev.
Regards, Roger
On 4/10/20 1:03 PM, Mark Kralj-Taylor wrote:
I'd like to help Java Clock.systemUTC() expose na
11 matches
Mail list logo
