Hi there,
we recently had a mini flood of bugs that only surfaced on Windows, and
even not reproducibly. I finally figured out the reason, and this mail
attempts to summarize the facts for future reference.
The short answer is: if you have see spurious problems on Windows, and
nobody can reproduce them on a *nix platform, it may be caused by
differences in how System.currentTimeMillis() works. You can verify that
this is the case by HAVING CHROME RUNNING ON THE SAME MACHINE. When the
problems go away, it's for the reasons I'll describe below.
The long explanation:
On Windows, Java's System.currentTimeMillis() is implemented in terms of
a Windows system call which returns the current time. That Windows
system time has a *configurable* granularity, where the historical
default is ~15ms (1000 / 64).
Programs can request a better granularity, and that effects the clock
behavior for *all* programs running on that machine. It also affects the
performance of the machine, though!
Programs known to do this are: Google Chrome, MS SQL server, IntelliJ
Idea, ...
See:
- a related OAK bug: <https://issues.apache.org/jira/browse/OAK-1564> --
this is actually about Jukka's work on a Clock class that might help us
get rid of System.currentTimeMillis()
- an article explaining the issue:
<http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/>
For debugging purposes, I recommend running Sysinternals's ClockRes tool
(<http://technet.microsoft.com/en-us/sysinternals/bb897568.aspx>) which
reports the current settings, and/or to run Windows' "powercfg" tool
("powercfg -energy duration 5"), which even reports what program caused
the current setting (note that that tool requires admin privileges and
for some reason doesn't work when invoked from Cygwin's bash).
Finally: never write code that expects System.currentTimeMillis() to
change more frequently than every ~15ms. That includes checks for
timestamps having changed, and also code that assumes that no two
timestamps are ever the same (by using them as key in a map).
Best regards, Julian
