JDK-8226575 : OperatingSystemMXBean should be made container aware
  • Type: Enhancement
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Affected Version: 11,13,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-06-21
  • Updated: 2020-07-29
  • Resolved: 2019-12-12
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 11 JDK 14 JDK 15 JDK 8
11.0.9Fixed 14 b27Fixed 15Fixed 8u261Fixed
Related Reports
CSR :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8236876 :  
When Java is running in a container many of the OperatingSystemMXBean accessor methods return host based information rather than container specific data.

jdk/open/src/jdk.management/unix/classes/com/sun/management/internal/OperatingSystemImpl.java contains these native methods which extract Host specific data.  These methods should be examine to determine if there is a container specific source of this information.

    private native long getCommittedVirtualMemorySize0();
    private native long getFreePhysicalMemorySize0();
    private native long getFreeSwapSpaceSize0();
    private native long getMaxFileDescriptorCount0();
    private native long getOpenFileDescriptorCount0();
    private native long getProcessCpuTime0();
    private native double getProcessCpuLoad0();
    private native double getSystemCpuLoad0();
    private native long getTotalPhysicalMemorySize0();
    private native long getTotalSwapSpaceSize0();

These Java methods should first try to extract this information from the internal container Metrics API, if available.  Otherwise it should call these existing native methods.

Here are the Container Metrics implementation classes:


I'm OpenJDK 8u backports of this. 8u needs a backport of JDK-8203357 (container metrics) as well. 8u: webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/ RFR: http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012178.html

Fix Request (OpenJDK 11u): Please approve backporting this to OpenJDK 11u. The plan is to also backport this to OpenJDK 8u (for Oracle JDK 8 parity) and it would be bad if we'd regress on the feature front in later JDKs. Thus, requesting a backport here too. The patch doesn't apply cleanly. What's more the patch from JDK 14 introduced new methods on OperatingSystemMXBean which isn't suitable for a backport to an LTS release. Instead, existing methods have been changed to return the container limit over the host system. This has been clarified in the javadoc and a CSR has been filed and got approved. The patch got reviewed by Andrew Dinn. I intend to push this with JDK-8236617 so as to not break testing. Risk should be fairly low since it only affects Linux and then only when run in a container. Testing: Included container tests on Linux x86_64. webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk11/02/webrev/ Corresponding CSR: https://bugs.openjdk.java.net/browse/JDK-8248804 RFR: http://mail.openjdk.java.net/pipermail/jdk-updates-dev/2020-July/003495.html

URL: https://hg.openjdk.java.net/jdk/jdk/rev/899254bd233b User: dtitov Date: 2019-12-12 03:22:51 +0000

Please see the CSR request - JDK-8228428 - for how this change evolved.

Updated comment as there are two OperatingSystemMXBean interfaces: - java.lang.management.OperatingSystemMXBean - com.sun.management.OperatingSystemMXBean (a subtype of the former) What the methods of these two interface report depends on exactly how the method has been specified. If it refers to something "available to the JVM (or current process)" then it needs to be container aware. If it refers to the "whole system" or something "physical", then that should report information for the whole system. Arguably some of the whole-system/physical APIs are misguided and reflect a history where containers and virtualized environments were not envisaged. But changing them is a compatability issue and so it may be better to add new methods that report more interesting/relevant information for the process's environment. Either way a CSR request will need to be filed and the changes examined from a compatibility perspective. Some of the APIs may not be "well formed" in the first place - for example getSystemLoadAverage(): "Returns the system load average for the last minute. The system load average is the sum of the number of runnable entities queued to the available processors and the number of runnable entities running on the available processors averaged over a period of time. " This refers to the "system" but specifies the calculation is based on "available processors" - which is a contradiction as "available" != "system".

The spec for java.lang.management.OperatingSystemMXBean::getAvailableProcessors: Returns the number of processors available to the Java virtual machine. This method is equivalent to the Runtime.availableProcessors() method. com.sun.management.OperatingSystemMXBean API provides the metrics for the operating system on which the Java virtual machine is running. I believe this issue may require spec clarification or update.

Originally reported here: http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-June/028439.html

Assigning to me on behalf of Andrew Azores. He'll be working on getting this fixed.