Yakov, For example: http://pzemtsov.github.io/2017/07/23/the-slow-currenttimemillis.html
>>> 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 time source. 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 > implementation. > > --Yakov >
