-
Bug
-
Resolution: Fixed
-
P2
-
8u20, 9
-
b16
-
x86
-
windows_7
-
Verified
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8062837 | 9 | Markus Grönlund | P2 | Resolved | Fixed | b40 |
JDK-8084202 | emb-9 | Markus Grönlund | P2 | Resolved | Fixed | team |
JDK-8066360 | 8u45 | Markus Grönlund | P2 | Resolved | Fixed | b01 |
JDK-8070056 | emb-8u47 | Markus Grönlund | P2 | Resolved | Fixed | team |
FULL PRODUCT VERSION :
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Gradle 1.11
A DESCRIPTION OF THE PROBLEM :
This bug sounds crazy, but it is 100% reproducible on multiple machines. If the gradle daemon is running *before* I start a separate java process which uses com.sun.management.OperatingSystemMXBean.getProcessCpuLoad() then the method will return the correct CPU load only while the gradle daemon is still running. Once the gradle daemon is stopped, getProcessCpuLoad() always returns -1. If the gradle daemon is started back up, getProcessCpuLoad() starts working again.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Download gradle 1.11 and add the bin directory to the path
2. In a command window, run gradle --daemon
3. In a separate window, execute the java app listed below
4. The app will begin outputting the current CPU load a few times per second. Initialli, it prints CPU: -1.000000, but quickly begins the correct value (i.e. CPU: 0.000000).
5. In the first command window, run gradle --daemon --stop
6. Verify that as soon as the gradle daemon stops, the test app reverts back to CPU: -1.000000.
7. Start the gradle daemon again using gradle --daemon
8. Verify that as soon as the gradle process starts, the test app begins producing real CPU load values.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In step 6 above, getProcessCpuLoad() should return the correct CPU load
ACTUAL -
In step 6 above, getProcessCpuLoad() returns -1 instead of the current process CPU load.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import com.sun.management.OperatingSystemMXBean;
import java.lang.management.ManagementFactory;
public class TestApp
{
private static final OperatingSystemMXBean mxBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);
private static double getProcessCpuLoad()
{
return mxBean.getProcessCpuLoad();
}
public static void main(String[] args) throws Exception
{
while (true)
{
System.out.printf("CPU: %f%n", getProcessCpuLoad());
Thread.sleep(100);
}
}
}
---------- END SOURCE ----------
java version "1.8.0_20"
Java(TM) SE Runtime Environment (build 1.8.0_20-b26)
Java HotSpot(TM) Client VM (build 25.20-b23, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
EXTRA RELEVANT SYSTEM CONFIGURATION :
Gradle 1.11
A DESCRIPTION OF THE PROBLEM :
This bug sounds crazy, but it is 100% reproducible on multiple machines. If the gradle daemon is running *before* I start a separate java process which uses com.sun.management.OperatingSystemMXBean.getProcessCpuLoad() then the method will return the correct CPU load only while the gradle daemon is still running. Once the gradle daemon is stopped, getProcessCpuLoad() always returns -1. If the gradle daemon is started back up, getProcessCpuLoad() starts working again.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Download gradle 1.11 and add the bin directory to the path
2. In a command window, run gradle --daemon
3. In a separate window, execute the java app listed below
4. The app will begin outputting the current CPU load a few times per second. Initialli, it prints CPU: -1.000000, but quickly begins the correct value (i.e. CPU: 0.000000).
5. In the first command window, run gradle --daemon --stop
6. Verify that as soon as the gradle daemon stops, the test app reverts back to CPU: -1.000000.
7. Start the gradle daemon again using gradle --daemon
8. Verify that as soon as the gradle process starts, the test app begins producing real CPU load values.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
In step 6 above, getProcessCpuLoad() should return the correct CPU load
ACTUAL -
In step 6 above, getProcessCpuLoad() returns -1 instead of the current process CPU load.
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import com.sun.management.OperatingSystemMXBean;
import java.lang.management.ManagementFactory;
public class TestApp
{
private static final OperatingSystemMXBean mxBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);
private static double getProcessCpuLoad()
{
return mxBean.getProcessCpuLoad();
}
public static void main(String[] args) throws Exception
{
while (true)
{
System.out.printf("CPU: %f%n", getProcessCpuLoad());
Thread.sleep(100);
}
}
}
---------- END SOURCE ----------
- backported by
-
JDK-8062837 getProcessCpuLoad() stops working in one process when a different process exits
- Resolved
-
JDK-8066360 getProcessCpuLoad() stops working in one process when a different process exits
- Resolved
-
JDK-8070056 getProcessCpuLoad() stops working in one process when a different process exits
- Resolved
-
JDK-8084202 getProcessCpuLoad() stops working in one process when a different process exits
- Resolved
- relates to
-
JDK-8019921 No CPULoad-events when recording a GlassFish instance
- Closed