It might be a good time to, again, systematically investigate the latency related to os::elapsed_counter().

Historically, the underlying counter sources exposed by the OS's (that os::elapsed_counter() maps) have been too slow for JFR purposes.
This is the background for still using raw rdtsc() in JFR, with an awareness of the problems it entails. We have not actively monitored the evolution in regards to the OS exposed counters, there are indications that access latencies have improved on certain platforms (OS / HW) in later years.

We should re-investigate the actual overhead of using os::elapsed_counter() in comparison to rdtsc().

The on-off capability already exist in the code, turning on / off can be handled using the following flag:

  experimental(bool, UseFastUnorderedTimeStamps, false,
          "Use platform unstable time where supported for timestamps only")

We need targeted tests (JFR JMH benchmarks) and access to modern hardware / OS combinations to accomplish this study.

In the best case, the latency is within acceptable bounds (tbd), and if that is the case, we could hopefully abandon rdtsc().