Currently `Rdtsc::initialize` may be called from the first ElapsedCounter now call. Currently this happens at different points during bootstrapping depending on what subsystem is active like JFR, which GC etc.
The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.
It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.
Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.
The GC use the elapsed counters (or Ticks) from non-JavaThreads. There is a problem here if Rdtsc has not been initialized before a non-JavaThread start using the system as is uses `JavaThread::current()->sleep(1)`. I suggest we change this to a `os::naked_short_sleep` to allow any type of thread to win the race of initializing Rdtsc. And also remove the strangeness of having our main thread go into blocked even before the VM thread has started.
It may be that we should also call the initialization unconditionally in a deterministic place. But I see that as a larger future enhancement.
Another question is whether we should support non-invariant rdtsc (even if it needs to be explicitly enabled by a user). I wonder of its usefulness when it will not be accurate, adds a startup cost, and most kernels are fast enough with much more accurate timing information.
- relates to
-
JDK-8369467 Rdtsc: Remove experimental support for non invariant tsc
-
- New
-
- links to
-
Review(master) openjdk/jdk/27710