JDK-4295241 : 1.3FCS-P,HotSpot,Solaris: Object.wait(timeout) waits for incorrect elapsed time
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,solaris_2.6,solaris_7
  • CPU: x86,sparc
  • Submitted: 1999-11-30
  • Updated: 2012-10-08
  • Resolved: 1999-12-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
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.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: kestrel INTEGRATED IN: kestrel
14-06-2004

EVALUATION y.s.ramakrishna@eng 1999-12-01: doesn't reproduce with latest (i.e. today's) 1.3-ref or hotspot_baseline builds. Trying to figure out the bug & how it got fixed (at a low priority). A preliminary inspection of the flow of timeout information through the VM to the final cond_timedwait call does not reveal any problems or any recent modifications. y.s.ramakrishna@eng 1999-12-06: A big hunk of changes involving code in objectMonitor_solaris.cpp came in with a merge from vick around 11 November, and which is now in 1.3-ref, and destined apparently for build R. The changes in that putback (which have been in the solaris tree for over 6 months, but for some strange reason not in the release builds) are likely the cause of the bug and its mysterious fix. Not much point in trying to identify the point in the solaris tree when the bug got fixed, but that point is clearly more than 3 months old. [i.e. blaming failure of merge process in the past]. Closing as fixed in build R. (i.e. kestrel). This problem occurs with the 12/09/99 binaries from: /net/mizu/usr/re/hotsparc_client1.3/binaries/solsparc/latest nancy.schorr@eng 1999-12-10 y.s.ramakrishna@eng 2000-01-05: It was determined (around Dec 10 or so) that the problem was caused only in the release builds, because of release engineering having used the SC 4.2 compilers. The correct compilers to use are the patched SC 5.0 compilers (more information at the URL file:/net/jde1.eng/export/jtechbig/hs/doc/web/ws.html#solaris_tools. Release engineering then addressed this problem by moving (around 10-12 Dec) to the correct set of compilers.
11-06-2004