[
https://issues.apache.org/jira/browse/CASSANDRA-19501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17831592#comment-17831592
]
Bret McGuire commented on CASSANDRA-19501:
------------------------------------------
Hat tip to [~alberto.bortolan] for bringing this to my attention!
> 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
