Github user franz1981 commented on the issue:
https://github.com/apache/activemq-artemis/pull/2481
Nice investigation! Anyway, CLOCK_MONOTONIC is not subject to NTP backward
adjustment, but just incremental ones ie clock acceleration of any kind, but
this would happen mostly for systems that shares a single common clock and I'm
sure that is not the common case.
Re the openjdk code, I was already aware of cases where nanoTime was
implemented using currentTimeMillis, but not that there was modern systems with
such issues given that not just this critical analyser, but probably anything
that measure time in a Java program would be broken if it happens.
My concern is to add a XADD instruction in the hot path to support this fix
given its cost.
Do you have verified that your system is not supporting nanoTime correctly?
Probably updating the kernel or just using something with hardware clock
dedicated would help.
---
