JDK-8056049 : getProcessCpuLoad() stops working in one process when a different process exits
  • Type: Bug
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 8u20,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86
  • Submitted: 2014-08-21
  • Updated: 2015-06-04
  • Resolved: 2014-11-07
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.
JDK 8 JDK 9
8u40 b16Fixed 9Fixed
Related Reports
Relates :  
Description
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 ----------


Comments
Verified with JDK 8u40 b22 using steps from description.
22-01-2015

ILW = MHH, P2, affects Windows platform, no workarounds
22-10-2014

Fix in progress.
22-10-2014

The root cause is exactly the same as in JDK-8019921
26-09-2014