Details
-
Type:
Improvement
-
Status:
Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: JRuby 1.1RC3
-
Fix Version/s: JRuby 1.2
-
Component/s: Core Classes/Modules
-
Labels:None
-
Environment:Linux
-
Number of attachments :
Description
Related to JRUBY-2698, on some operating systems (e.g. linux), System.nanoTime() is not monotonically increasing.
i.e. with two successive calls to System.nanoTime(), the second call can return a value less than the first call.
This makes Time.now run backwards, which people assume should not happen. Although its not a valid assumption, especially on multi-cpu machines, people write code with that assumption, and jruby can break their code.
The attached code snippet demonstrates one possible workaround - it stores the last time retrieved, and only returns the new value from System.nanoTime() if it is greater than the stored value.
It has a couple of downsides, namely its more complex, and with multiple threads calling it, it will hammer the memory bus as it updates the global variable.
It needs someone else to verify that MonoTime.nanoTime() is indeed correct under all circumstances.
Issue Links
- is related to
-
JRUBY-2698
Time.new inconsitencies
-
I noticed the decreasing results out of gettimeofday and System.nanoTime() on my Ubuntu 8.04 (running inside VirtualBox on Windows!).
When tried on Fedora Core 6 on real hardware, I couldn't reproduce that strange behavior.
Asking Google, it seems that there are gettimeofday related bugs in some Linux kernels though...