Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6900441

PlatformEvent.park(millis) on Linux could still be affected by changes to the time-of-day clock

    Details

    • Subcomponent:
    • Resolved In Build:
      b109
    • CPU:
      generic, x86, ppc
    • OS:
      linux, linux_ubuntu

      Backports

        Description

        This is a continuation of 6311057 which only partially "fixed" the problem because Linux itself is operating incorrectly in this area. I have it on good authority that "The futex wait implementation is historically wrong." and that "I think with newer kernel/glibc combinations it will be correct."

        The real fix here is to change the pthread_cond so that it is associated with the monotonic clock (pthread_condattr_setclock(CLOCK_MONOTONIC) - and with pthread_cond_init being passed the attr object) and to calculate the asbolute time as "millis from now" on the monotonic clock. This will make the PlatformEvent::park(millis) code immune to changes in the time-of-day clock.

        This change is relatively simple but it does affect all timed-waiting calls that ultimately use PlatformEvent. This should be okay as the majority of Java APIs that involve timed-waiting all specify relative times the same as Thread.sleep. I believe this will cover Thread.sleep and Object.wait.

        Note that there is a similar problem with the java.util.concurrent.locks.LockSupport.park methods which are implemented using the platform specific Parker class, which again uses a pthread_mutex and pthread_cond under the covers. However as they support both absolute and relative wait times the fix is more involved as we need to use the monotonic clock for relative waits, but the TOD clock for absolute ones! That would require using two different pthread_cond objects.

        Update: Note that time jump forwards lead to early returns. For os::sleep there is a guard in place to prevent this already. For wait(ms) and park(nanos) such a guard could also be implemented but is unnecessary in practice because an early timeout can not be distinguished from a "spurious wakeup" which is permitted by the spec and which Java code has to account for.
        1. SleepTracing.diffs
          5 kB
          Ron Durbin
        2. TimeJumpWithSleep.java
          9 kB
          Ron Durbin
        3. TimeJumpWithSleep.log
          5 kB
          Ron Durbin
        4. TimeJumpWithWait.java
          9 kB
          Ron Durbin
        5. TimeJumpWithWait.log
          5 kB
          Ron Durbin

          Issue Links

            Activity

            Hide
            aeriksso Andreas Eriksson (Inactive) added a comment -
            Yes, I can test your fix if you need, I have a system that it reproduces on.
            Show
            aeriksso Andreas Eriksson (Inactive) added a comment - Yes, I can test your fix if you need, I have a system that it reproduces on.
            Hide
            dholmes David Holmes added a comment -
            Changed Fix Version from 9 to 8. Unfortunately the 9 caused a backport issue for hs25 to be created instead of using this as the main issue. This issue will now be used for 8.
            Show
            dholmes David Holmes added a comment - Changed Fix Version from 9 to 8. Unfortunately the 9 caused a backport issue for hs25 to be created instead of using this as the main issue. This issue will now be used for 8.
            Hide
            dholmes David Holmes added a comment -
            There is no regression test for this as the available tests need to be run manually with superusers privileges on a system where we can mess with the system time.
            Show
            dholmes David Holmes added a comment - There is no regression test for this as the available tests need to be run manually with superusers privileges on a system where we can mess with the system time.
            Hide
            hgupdate HG Updates added a comment -
            URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/2e6938dd68f2
            User: amurillo
            Date: 2013-09-24 21:09:48 +0000
            Show
            hgupdate HG Updates added a comment - URL: http://hg.openjdk.java.net/jdk8/jdk8/hotspot/rev/2e6938dd68f2 User: amurillo Date: 2013-09-24 21:09:48 +0000
            Hide
            mcastegr Mattis Castegren (Inactive) added a comment -
            The backport to JDK6 is turning out to be problematic. We are currently investigating options, but we will not be able to take this to the January CPU. Removing critical-watch.
            Show
            mcastegr Mattis Castegren (Inactive) added a comment - The backport to JDK6 is turning out to be problematic. We are currently investigating options, but we will not be able to take this to the January CPU. Removing critical-watch.

              People

              • Assignee:
                dholmes David Holmes
                Reporter:
                dholmes David Holmes
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Imported:
                  Indexed: