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

1.3FCS-P,HotSpot,Solaris: Object.wait(timeout) waits for incorrect elapsed time

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • P2
    • 1.3.0
    • 1.3.0
    • hotspot
    • kestrel
    • x86, sparc
    • generic, solaris_2.6, solaris_7

    Description

      With 1.3 (kestrel) FCS build P on Solaris (2.6 & 2.7) and the hotspot VM, the method wait(timeout) of java.lang.Object seems to ignore the supplied timeout value and instead wait a fixed time (around 513000 ms). This behavior breaks code that uses Object.wait(timeout) to effect time-based actions. One particular example is that with this bug, RMI's distributed garbage collection implementation fails to renew DGC leases in time. I would imagine that the java.util.Timer class would also be quite adversely affected by this bug, since its implementation also uses Object.wait(timeout).

      [For what it's worth, Thread.sleep(millis) does not seem to have the same bug.]

      The test case "TimedWait" below demonstrates the bug. It should terminate after waiting 10 seconds (in between output messages), but with build P on Solaris, using the hotspot VM, it waits much longer (around 8 minutes and 33 seconds on the couple of 2.6 Ultra 60 machines and the one 2.7 machine that I have tested it on). In fact, Object.wait(timeout) seems to wait that same duration even if the supplied timeout is even much shorter or even longer (see example output below).

      On win32, or with build O (or even with my up-to-date workspace build), or with the classic VM, this test behaves as expected, waiting only 10 seconds.

      public class TimedWait {
          public static void main(String[] args) {
              try {
                  long duration;
                  if (args.length > 0) {
                      duration = Long.parseLong(args[0]);
                  } else {
                      duration = 10 * 1000;
                  }
       
                  Object lock = new Object();
       
                  System.err.println("# beginning to wait " + duration + " ms:");
                  synchronized (lock) {
                      lock.wait(duration);
                  }
                  System.err.println("# finished waiting " + duration + " ms.");
              } catch (Exception e) {
                  e.printStackTrace();
              }
          }
      }

      Here is some example output of this test case on a Solaris 2.6 machine (zaphod.east) using build 1.3 FCS build P. Note that for all durations (the default 10 seconds, only 1 milliseconds, and 10 minutes), the Object.wait(timeout) call appears to wait for around 8 minutes and 33 seconds:

      [zaphod] 134 % /usr/bin/time java TimedWait
      # beginning to wait 10000 ms:
      # finished waiting 10000 ms.

      real 8:33.0
      user 0.3
      sys 0.2

      [zaphod] 135 % /usr/bin/time java TimedWait 1
      # beginning to wait 1 ms:
      # finished waiting 1 ms.

      real 8:33.7
      user 0.3
      sys 0.2

      [zaphod] 137 % /usr/bin/time java TimedWait 600000
      # beginning to wait 600000 ms:
      # finished waiting 600000 ms.

      real 8:33.0
      user 0.4
      sys 0.1

      [zaphod] 140 % java -version
      java version "1.3.0"
      Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-P)
      Java HotSpot(TM) Client VM (build 1.3-P, interpreted mode)

      [zaphod] 141 % uname -r
      5.6

      harshad.vilekar@eng 1999-12-02 FCS build 1.3-P

      java.util.Timer schedule() and scheduleAtFixedRate() methods are failing
      on Solaris due to this.

      Attachments

        Issue Links

          Activity

            People

              ysr Y. Ramakrishna
              peterjones Peter Jones
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:
                Imported:
                Indexed: