Bret McGuire created CASSANDRA-19501:
----------------------------------------
Summary: 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
Assignee: Henry Hughes
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().
--
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
