JRuby

Make Time.now monotonically increasing

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor 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 :
    1

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.

  1. Java Source File
    Main.java
    13/Jul/08 7:36 AM
    2 kB
    Wayne Meissner

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. JRUBY-2698 Time.new inconsitencies

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Vladimir Sizikov made changes -
Field Original Value New Value
Link This issue is related to JRUBY-2698 [ JRUBY-2698 ]
Hide
Permalink
Vladimir Sizikov added a comment -

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...

Show
Vladimir Sizikov added a comment - 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...
Hide
Permalink
Wayne Meissner added a comment -

More info on gettimeofday() and friends on linux with multi-core and/or power saving here: http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

Show
Wayne Meissner added a comment - More info on gettimeofday() and friends on linux with multi-core and/or power saving here: http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html
Thomas E Enebo made changes -
Component/s Core Classes/Modules [ 12230 ]
Hide
Permalink
Charles Oliver Nutter added a comment -

Oddly enough, removing the nanotime logic completely still passes all tests and won't suffer from the same issues as using a nanotime offset. I tested our own tests, rubyspec, and rails, and they were all fine with new time instances always starting with usec = 0. I think we must have added the nanoTime stuff believing we needed to present it for new time instances, when in actuality we only need to preserve usec if it's modified or results from time calculations. Fixed in r9185.

Show
Charles Oliver Nutter added a comment - Oddly enough, removing the nanotime logic completely still passes all tests and won't suffer from the same issues as using a nanotime offset. I tested our own tests, rubyspec, and rails, and they were all fine with new time instances always starting with usec = 0. I think we must have added the nanoTime stuff believing we needed to present it for new time instances, when in actuality we only need to preserve usec if it's modified or results from time calculations. Fixed in r9185.
Charles Oliver Nutter made changes -
Resolution Fixed [ 1 ]
Status Open [ 1 ] Resolved [ 5 ]
Fix Version/s JRuby 1.2 [ 14757 ]
Assignee Vladimir Sizikov [ vvs ] Charles Oliver Nutter [ headius ]
Charles Oliver Nutter made changes -
Status Resolved [ 5 ] Closed [ 6 ]

People

  • Assignee:
    Charles Oliver Nutter
    Reporter:
    Wayne Meissner
Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: