The slow currentTimeMillis()

This post has a confused notion of why the TSC isn't used. It has nothing to do with integration with NTP -- it's because the kernel thinks the TSC doesn't work right on the machine in question. The kernel logs should explain why. Also, on some hypervisors, there are TSC problems, but the situation is slowly improving.

Also:

> The second value is the nanoseconds time, relative to the last second, shifted left by gtod->shift, Or, rather, it the time measured in some units, which becomes the nanosecond time when shifted right by gtod->shift, which, in our case, is 25. This is very high precision. One nanosecond divided by 225 is about 30 attoseconds. Perhaps, Linux kernel designers looked far ahead, anticipating the future when we’ll need such accuracy for our time measurement.

That's not what's going on. This is straightforward fixed point arithmetic, where the point just happens to be variable.

Theo Schlossnagle and Riley Berton have recently implemented and discussed timing functions with the following performance characteristics (25-50ns):

  Operating System  Call          System Call Time  Mtev-variant Call	Speedup
  Linux 3.10.0      gettimeofday  35.7 ns/op        35.7 ns/op          x1.00
  Linux 3.10.0	    gethrtime     119.8 ns/op       40.4 ns/op          x2.96
  OmniOS r151014    gettimeofday  304.6 ns/op       47.6 ns/op          x6.40
  OmniOS r151014    gethrtime     297.0 ns/op       39.9 ns/op          x7.44

Here is the article: https://www.circonus.com/2016/09/time-but-faster/

They also use TSC and (CPU-bound) background threads to update shared memory.

The implementation is available as C library for Linux and Illumos/OmniOS: https://github.com/circonus-labs/libmtev/blob/master/src/uti...

Related and required reading if you're doing microbenchmarking: https://shipilev.net/blog/2014/nanotrusting-nanotime/

Also the, tsc CPU flag is not sufficient since early tsc implementations had issues that made them unusuable for walltime measurements. There's also constant_tsc and nonstop_tsc which are relevant because they indicate that tsc keeps ticking independent of frequency scaling and CPU low power modes, only then do they become usable for low-overhead userspace timekeeping.

hotspot and the linux vDSO generally take care of doing the right thing, depending on CPU flags, so the TSC is used for currentTimeMillis and nanoTime if it can determine that it is reliable, otherwise more expensive but accurate methods are used.

The article's own conclusion:

> The title isn’t completely correct: currentTimeMillis() isn’t always slow. However, there is a case when it is.

It only happens under circumstances where the TSCs are not used.

Is this really new? I remember when System.nanoTime was introduced in the early 2000s largely because of the reasons stated here. System.currentTimeMillis was slow and had jitter which made it non-monotonic but it was the best method to call if your timestamp needed to interact with the world outside the JVM. In contrast, if all you cared about was relative times, you'd get a speed and accuracy boost from using System.nanoTime since it actually was monotonic and while a single nanosecond value was pretty meaningless, the difference between two nanosecond values was basically accurate.

Benchmarks are a class of problems where the overall time doesn't matter, only the relative time (end - start). The fact that he's using System.currentTimeMillis for his start and end values doesn't give me confidence that he's very knowledgeable about what's to follow.

Good analysis, and yet again, this is why we use TSC at Netflix. I benchmarked them all a while ago. I also put "clocksource" on my tools diagram, so people remember that clocksource is a thing: http://www.brendangregg.com/Perf/linux_perf_tools_full.png

> The vDSO is mapped to a new address each time (probably, some security feature). However, the function is always placed at the same address as above (0x00007ffff7ffae50) when run under gdb (I’m not sure what causes this).

GDB (≥ 7) disables ASLR by default:

https://sourceware.org/gdb/current/onlinedocs/gdb/Starting.h...

"The way to test the performance of System.currentTimeMillis() is straightforward"

I'd be worried about that claim. The article executes System.currentTimeMillis in a loop and sums the values. That takes care of dead code elimination, but it will still be subject to other distortionary effects (https://shipilev.net/#benchmarking-1). Maybe the fact that System.currentTimeMillis() is implemented using native code reduces some of the JIT induced benchmarking pitfalls, but I would still prefer to try and use JMH to test.

I'm also surprised that performance of System.currentTimeMillis can fall down so far under some circumstances. In one of Cliff Click's talks (maybe https://www.youtube.com/watch?v=-vizTDSz8NU), he mentions that some JVM benchmarks run it many millions of times a second.

This is especially relevant if you're running in the cloud.

We've recently run into slow performance with gettimeofday on Xen systems, such as EC2 (see: https://blog.packagecloud.io/eng/2017/03/08/system-calls-are...) This hits particularly hard if you're running instrumented code. Switching the clocksource from xen to tsc seems to help and we're still evaluating the ramifications of doing so (various sources including the above seem to suggest that tsc is unsafe and prone to clock skew, but others suggest that it's ok on more modern processors.)

Most Android developers will know this already, but currentTimeMillis() is probably not the call you want for event timing:

https://developer.android.com/reference/android/os/SystemClo...

The Windows version is absolutely brilliant: a shared area mapped into every process. Because of the way page tables work, this costs only one page (4k) of RAM and only has to be written once by the OS.

On a properly configured environment TSC is the default clocksource. I have no idea why one would want to precisely measure time with any other clock source.

On relatively contemporary systems clock_gettime(CLOCK_REALTIME) will give you a nanosecond resolution wall clock time and the cost of going through JNI will cost you around 11-13ns, so with a simple native wrapper in java the cost is negligible. Although interesting, the whole study of the cost of obtaining the current time in Java with currentTimeMillis() with clock sources other than TSC is somewhat irrelevant.

So there's a performance bug in Java's currentTimeMillis() implementation on Linux, where it uses gettimeofday() instead of clock_gettime() with a coarse timer (even the TSC method is ~3x slower or worse than the coarse timer, which has sufficient precision for currentTimeMillis()). Is there a bug filed for this? It seems to warrant one.

For what it's worth, currentTimeMillis() shouldn't be used for interval measurements anyway, as it might not be continuous in some scenarios. A better alternative is System.nanoTime().

People have been discovering and rediscovering gettimeofday is really slow for a long time now. I remember switching to OS specific equivalents for AIX, SunOS, Ultrix, HP-UX, etc. back in the late 80s and early 90s.

I started off being able to mostly comprehend what's going on, but about half way down I got lost in the assembly and realized I barely remember much from my OS/Architecture courses in school.

This was a solid reminder my every day work sits atop the shoulders of giants and I am much appreciative.

An easy way to do this from the outside would be to create a JVMTI agent, and make currentTimeMillis call into your JNI version. Here's an example in Rust of me doing it for a bit more involved purpose: https://github.com/cretz/stackparam. Then people only have to pass your shared lib as a cli arg to get the benefit.

> Some background thread regularly updates three double-words there, which contain the high part of the value, the low part, and the high part again.

So to implement a clock, they are using a different thread that updates a counter every millisecond or so? Isn't this a bit inefficient?

Really love these kind of in depth investigations. However, I still want to know how windows manages to update the value in the shared memory so consistently without any impact to system performance.

It's sort of amazing that 600 ns is considered slow.

I think I've also read somewhere about a bug in the java Random class, it was something about after N iterations, the number starts from iteration 1 where N is not very big (i.e. clearly visible pattern/cyclic repeat in the numbers). But I can't find it anymore, if someone knows its whereabouts, please let me know.

I've added an update on the nanoTime() to the article