Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2197120 | 7 | Daniel Daugherty | P3 | Closed | Fixed | b109 |
JDK-2197898 | 6u23 | Daniel Daugherty | P3 | Resolved | Fixed | b01 |
JDK-2199800 | 6u22m | Daniel Daugherty | P3 | Resolved | Fixed | b01 |
JDK-2197607 | 6u21p | Daniel Daugherty | P3 | Resolved | Fixed | b03 |
FULL PRODUCT VERSION :
java version "1.6.0_07" (hotspot client VM)
1.6.0u16, for Linux.
ADDITIONAL OS VERSION INFORMATION :
Linux kernel 2.6.18/Ubuntu 8.04
A DESCRIPTION OF THE PROBLEM :
The getCurrentThreadCpuTime method is extremely slow on Linux, due to its use of /proc entry for getting thread CPU timing information.
To wit, the submitted test case takes almost 4 seconds to do 100k CPU measurements, where as the IBM Linux JDK takes only 144 ms (25x faster) on the same machine.
Specifically, upon reviewing the source code for JDK 1.6u7, it appears that while there is an implementation of fast Posix based CPU timing measurement, it is disabled in hotspot\src\os\linux\vm\globals_linux.hpp (UseLinuxPosixThreadCPUClocks is defined to be false).
The constant is defined the same way in JDK 1.6u18 and August version of JDK 1.7, so this problem persists even in those later versions.
A fix would appears to be as simple as defining the UseLinuxPosixThreadCPUClocks to be true, so that the fast CPU time measurement implementation can be turned on.
I have downloaded and tested the bug against the latest version of JRE, 1.6.0u16, for Linux.
The bug still exists and the performance is still just as slow. The IBM JVM continues to be 25x faster than the Sun Java 6 update 16 JVM on the same hardware.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Please run submitted test code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Took: 144 ms.
(as run and recorded on IBM Linux JDK)
ACTUAL -
Took: 3700 ms.
(as run and recorded on Sun JDK on the same machine; about 25x slower)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public static void main(String[] args) {
long base = cputime();
for(int k = 0; k < 100 * 1000; k++) {
cputime();
}
System.out.println("Took: " + ((cputime() - base) / 1000.0 / 1000.0) + " ms.");
}
private final static long cputime() {
return java.lang.management.ManagementFactory.getThreadMXBean()
.getCurrentThreadCpuTime();
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The Oracle/BEA JRockit JVM and Sun JVM on Linux both exhibit this problem. The only workaround is to run the Windows version of the Sun JDK, or switch to the IBM version of JDK on Linux, which does not have this problem.
java version "1.6.0_07" (hotspot client VM)
1.6.0u16, for Linux.
ADDITIONAL OS VERSION INFORMATION :
Linux kernel 2.6.18/Ubuntu 8.04
A DESCRIPTION OF THE PROBLEM :
The getCurrentThreadCpuTime method is extremely slow on Linux, due to its use of /proc entry for getting thread CPU timing information.
To wit, the submitted test case takes almost 4 seconds to do 100k CPU measurements, where as the IBM Linux JDK takes only 144 ms (25x faster) on the same machine.
Specifically, upon reviewing the source code for JDK 1.6u7, it appears that while there is an implementation of fast Posix based CPU timing measurement, it is disabled in hotspot\src\os\linux\vm\globals_linux.hpp (UseLinuxPosixThreadCPUClocks is defined to be false).
The constant is defined the same way in JDK 1.6u18 and August version of JDK 1.7, so this problem persists even in those later versions.
A fix would appears to be as simple as defining the UseLinuxPosixThreadCPUClocks to be true, so that the fast CPU time measurement implementation can be turned on.
I have downloaded and tested the bug against the latest version of JRE, 1.6.0u16, for Linux.
The bug still exists and the performance is still just as slow. The IBM JVM continues to be 25x faster than the Sun Java 6 update 16 JVM on the same hardware.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Please run submitted test code.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Took: 144 ms.
(as run and recorded on IBM Linux JDK)
ACTUAL -
Took: 3700 ms.
(as run and recorded on Sun JDK on the same machine; about 25x slower)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public static void main(String[] args) {
long base = cputime();
for(int k = 0; k < 100 * 1000; k++) {
cputime();
}
System.out.println("Took: " + ((cputime() - base) / 1000.0 / 1000.0) + " ms.");
}
private final static long cputime() {
return java.lang.management.ManagementFactory.getThreadMXBean()
.getCurrentThreadCpuTime();
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
The Oracle/BEA JRockit JVM and Sun JVM on Linux both exhibit this problem. The only workaround is to run the Windows version of the Sun JDK, or switch to the IBM version of JDK on Linux, which does not have this problem.
- backported by
-
JDK-2197607 Linux getCurrentThreadCpuTime is drastically slower than Windows
-
- Resolved
-
-
JDK-2197898 Linux getCurrentThreadCpuTime is drastically slower than Windows
-
- Resolved
-
-
JDK-2199800 Linux getCurrentThreadCpuTime is drastically slower than Windows
-
- Resolved
-
-
JDK-2197120 Linux getCurrentThreadCpuTime is drastically slower than Windows
-
- Closed
-
- relates to
-
JDK-8338947 Deprecate the UseLinuxPosixThreadCPUClocks flag and remove it in a future release
-
- Resolved
-
-
JDK-6200022 JVMTI GetCurrentThreadCpuTime slow on Linux
-
- Resolved
-
(1 relates to)