[
https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bret McGuire updated CASSANDRA-19501:
-------------------------------------
Description:
As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the Java
driver relies on System.nanoTime() for it's impl of Native.gettimeofday() on
GraalVM. Underlying rationale there was a [substitution on older Substrate
impls
|https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58]
which appeared to rely on gettimeofday() for it's replacement of
System.nanoTime(). This was an unfortunate misreading of the source; it falls
back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, and on
most modern systems that won't fail at all. In fact new versions of GraalVM
[don't even bother with the fallback|#L37-L53].]. That leaves us returning
values from the monotonic clock as answers to gettimeofday() ops and those
values... do not correlate to the time of day at all.
Seems like the simplest answer is just to inline the gettimeofday() logic into
GraalLibc.gettimeofdayRaw().
was:
As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the Java
driver relies on System.nanoTime() for it's impl of Native.gettimeofday() on
GraalVM. Underlying rationale there was a [substitution on older Substrate
impls
|https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58]
which appeared to rely on gettimeofday() for it's replacement of
System.nanoTime(). This was an unfortunate misreading of the source; it falls
back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails, and on
most modern systems that won't fail at all. In fact new versions of GraalVM
[don't even bother with the
fallback|[https://github.com/oracle/graal/blob/jdk-17.0.10/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L37-L53].]
Seems like the simplest answer is just to inline the gettimeofday() logic into
GraalLibc.gettimeofdayRaw().
> GraalLibc.gettimeofday() is misbehaving in new GraalVM versions
> ---------------------------------------------------------------
>
> Key: CASSANDRA-19501
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19501
> Project: Cassandra
> Issue Type: Bug
> Components: Client/java-driver
> Reporter: Bret McGuire
> Priority: Normal
>
> As of [JAVA-2663|https://datastax-oss.atlassian.net/browse/JAVA-2663] the
> Java driver relies on System.nanoTime() for it's impl of
> Native.gettimeofday() on GraalVM. Underlying rationale there was a
> [substitution on older Substrate impls
> |https://github.com/oracle/graal/blob/release/graal-vm/20.0/substratevm/src/com.oracle.svm.core.posix/src/com/oracle/svm/core/posix/linux/LinuxSubstitutions.java#L41-L58]
> which appeared to rely on gettimeofday() for it's replacement of
> System.nanoTime(). This was an unfortunate misreading of the source; it
> falls back to gettimeofday() iff clock_gettime() on CLOCK_MONOTONIC fails,
> and on most modern systems that won't fail at all. In fact new versions of
> GraalVM [don't even bother with the fallback|#L37-L53].]. That leaves us
> returning values from the monotonic clock as answers to gettimeofday() ops
> and those values... do not correlate to the time of day at all.
>
> Seems like the simplest answer is just to inline the gettimeofday() logic
> into GraalLibc.gettimeofdayRaw().
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
