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. Main.java
        2 kB
        Wayne Meissner

        Issue Links

          Activity

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

            People

            • Assignee:
              Charles Oliver Nutter
              Reporter:
              Wayne Meissner
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: