Computation of CPU time in ThreadMXBean.getCurrentThreadCpuTime() is sometimes wrong, in an unpredictible way.

This is causing problems in the JES Monitoring Framework, as we rely on this API to return the CPU time consumed by a JES Service. This breaks many of our APIs.

Sometimes, getCurrentThreadCpuTime() returns high values, typical values are in the range of 779041925179556800, which corresponds to a CPU running time for the current thread of about 24 years.

I'm using Java 5.0 FCS (released last week) on Solaris 10 b60 (SunOS pae44 5.10 s10_60 sun4u sparc SUNW,Sun-Fire-480R)

This shows up very easily and quickly (in less than 1 second) in a test program:

public class TestTiger {
  public static void main(String[] args) {
    java.lang.management.ThreadMXBean bean = java.lang.management.ManagementFactory.getThreadMXBean();
    for (;;) {
      long t = bean.getCurrentThreadCpuTime();
      if (t>100000000000000000L) {
        System.out.println("SantaClara, we got a problem: t = "+t);
        t = bean.getCurrentThreadCpuTime();
        System.out.println("The problem happened after "+t+" ns of CPU time ("+((float)t/1000000000)+" sec)");
        break;
      }
    }
  }
}

Example of execution:

$ ksh do_test_tiger
SantaClara, we got a problem: t = 792034979053554300
The problem happened after 372237100 ns of CPU time (0.3722371 sec)
$ ksh do_test_tiger
SantaClara, we got a problem: t = 792035106892070900
The problem happened after 502100800 ns of CPU time (0.5021008 sec)
$ ksh do_test_tiger
SantaClara, we got a problem: t = 792035201730809000
The problem happened after 299941700 ns of CPU time (0.2999417 sec)
$
###@###.### 10/7/04 06:07 GMT

I verified that this bug is indeed fixed in s10_b64. Good job !
###@###.### 10/11/04 11:46 GMT