>>> We’ve learned that the slow execution of currentTimeMillis() was caused
by two factors:
>>> - JVM using gettimeofday() instead of clock_gettime()
>>> - gettimeofday() being very slow if HPET time source is used.
You mat get slow currentTimeMillis() - up to 1mcs - unless you set proper
On Wed, Aug 9, 2017 at 4:15 PM, Yakov Zhdanov <yzhda...@apache.org> wrote:
> As Dmitry P mentioned System.currentTimeMillis() is JVM intrinsic.
> Moreover, there is a daemon thread that updates the internal value which
> will not be needed after the change.
> If we remove U.currentTimeMillis() code will become more clear and
> consistent. Why we think that we can implement this particular timer better
> than JVM developers?
> Vladmir, can you please share a benchmark that will show the problems? If
> it will then it will be a strong argument to keep the current