RFR: 8226575: OperatingSystemMXBean should be made container aware

[David Holmes]

Hi Andrew,

Sorry - this whole discussion slipped past me while I was traveling in 
the US in late June (and have then been on vacation). As I just wrote in 
the bug report:

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 compatibility 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".

So I think we need to take a step back at the moment and look at exactly 
which methods can be container-aware based on their current 
specification, and which should be container-aware but can't be because 
of their current specification, and so what new methods may be needed.

David
-----

On 18/07/2019 4:45 am, Andrew Azores wrote:
> Hi all,
> 
> Please review this change that addresses JDK-8226575 according to a
> previous discussion on this list [0][1]. The webrev has been kindly
> uploaded on my behalf by Severin Gehwolf, since I am not an author.
> 
> The initial problem was that the
> com.sun.management.OperatingSystemMXBean was inconsistent about its
> awareness of applicable container limits. On the one hand, the
> (inherited) getAvailableProcessors() return value is consistent with
> the container-aware Runtime.availableProcessors(). But on the other
> hand, c.s.m.OperatingSystemMXBean's getTotalPhysicalMemorySize(),
> getFreePhysicalMemorySize(), getTotalSwapSpaceSize(), and
> getFreeSwapSpaceSize() returned values reflecting the physical host
> machine with no awareness of container limits. getSystemCpuLoad() has
> also been updated to use cgroup-accounted load calculation.
> 
> The fix applied is to use the JDK internal Metrics API to determine
> container memory limits and CPU accounting and use these values
> instead, if available, otherwise falling back on the pre-existing
> native implementations.
> 
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8226575
> 
> webrev:
> http://cr.openjdk.java.net/~sgehwolf/webrevs/aazores/JDK-8226575/01/webrev/
> 
> [0]
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-June/028439.html
> [1]
> http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028709.html
> 
> Thanks,
>