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,
