JDK-4313182 : Thread.sleep(millis, nanos) sleeps for incorrect time.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.3.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2000-02-16
  • Updated: 2002-08-15
  • Resolved: 2002-08-14
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
With kestrel-rc1 the method sleep(millis, nanos) if the java.lang.Thread seems
to sleeps a shorter periof of time then specified by parameters.
For ex: thread with sleep(1000,1000) actually sleeps an about 970 millisec only with execution on 2 ways Ultra-2.

With execution on the same machine but under JDK1.2.2 Solaris refs. the time is equal to 1010 millisec.

The following simple test is passed on JDK1.2.2 and is failed with Kestrel.

class test extends Thread {
    boolean done=true;
    long sleepTime=0;

    public void run() {
	long lTime=System.currentTimeMillis();
	try{sleep(1000,1000);}
	catch(Exception E){}
	sleepTime=System.currentTimeMillis()-lTime;
	done=true;
    }

    static void SleepTest() {
	test Th1=new test();
	Th1.start();
	try { Th1.join(); }
	catch (InterruptedException itr){ }
	System.out.println("Actual sleep time is " + Th1.sleepTime);
	if (Th1.sleepTime < 1000) {
	    System.out.println("Test failed.");
	    System.exit(1);
	}
    }

    public static void  main(String arg[]) {
	test.SleepTest();
    }
}     

konstantin.boudnik@eng 2000-02-16

Comments
WORK AROUND A workaround in the VM code would be to adjust upwards a la ExactVM. But Roger Faulkner informs us that the fix will be put back to the kernel soon, so it's probably best to wait .... ?
11-06-2004

EVALUATION y.s.ramakrishna@eng 2000-02-16: it's independent of # cpu's. Thread.sleep() uses select for timeout & System.currentTimeMillis() uses gettimeofday(). As far as i know both use the same time-base, so we shouldn't see this anomaly, but the assumption that both use the same time-base should be verified first. (see also some related comments in the "Comments" section). y.s.ramakrishna@eng 2000-02-16: After some digging around and some investigation here's some pertinent email from Roger Faulkner, from which I will conclude that we should make this bug shadow the kernel bug mentioned in the following email and (if possible request backports and) verify when that bug is fixed that our bug is indeed not present. Date: Wed, 16 Feb 2000 19:06:22 -0800 (PST) From: "Roger A. Faulkner" <###@###.###> To: ###@###.### Subject: Re: quick question re select Cc: ###@###.### > From ###@###.### Wed Feb 16 15:47:05 2000 > Subject: quick question re select > To: ###@###.###, ###@###.### > > Hi Roger/Devang -- quick question: select(3C) appears to timeout somewhat > earlier than requested; at least as measured by gettimeofday(). > Could you shed some light? [Could it be because of some internal > conversions and rounding errors inside the kernel? If so, how easy > might this be to fix (without requiring the caller of select to make > an appropriate adjustment upwards)?] > > If you know someone else who i should be asking this question please > let me know. > > thanks! and sorry to bother you with this stuff (which i am sure is > quite peripheral to your interests :) > -- ramki. This is a kernel bug: 4308370 cond_timedwait(), sigtimedwait(), poll() and /proc time out too soon I have the fix done; i just have to put it back to /ws/on81-gate Roger ###@###.### 2002-08-14 In addition to the kernel fix, the fix from JVM 1.2.x was rolled forward to JVM 1.4.0 (merlin-beta3) in 4503551.
14-08-2002