Hi All, I've filed a CSR and would like to solicit feedback at this point. There are some contradicting issues involved and IMHO there is no clear-cut answer to a couple of key points.
https://bugs.openjdk.java.net/browse/JDK-8228428 This is still a Work-In-Progress :) Comments inline. On Fri, 2019-07-19 at 08:27 -0700, Mandy Chung wrote: > > On 7/18/19 3:49 PM, David Holmes wrote: > > 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. > > > > Agree. > > When the APIs were introduced, it was defined for the whole system and > the spec should be made clear. If the APIs should be made > container-aware, the spec should be clarified of the new behavior. > > Monitoring the whole system still provides a useful view even on a > container and virtualized environment. Right, but going to the extreme, when a JVM runs inside a full virtualized VM it reports it's view from *within* the VM, not the whole system (the host the vm runs under). While it might be useful, I'm not sure what the approach of "least surprises" would be. The JVM in a container with a memory limit won't use the hosts' full memory resources. > One idea to consider would be > to refactor com.sun.management.OperatingSystemMXBean and extract the > container-aware methods in a new MXBean which OSMXBean extends and > create one new singleton instance of the new MXBean to report > container-specific metrics. It would be platform specific, though. My reading of JDK-8199944 suggests this is a dead end. > > 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 should be updated to "system" in this case. You mean "available processors averaged" => "system processors averaged"? If so, should the method name of getAvailableProcessors() be changed too? > > 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. > > > > Bob's suggestion [1] to make the total/free physical memory and swap > space size container-aware sounds reasonable. +1 It makes a lot of sense given how the JDK works otherwise in those quota'ed environments. Thanks, Severin > Refactoring c.s.m.OperatingSystemMXBean could be one option to explore. > > Mandy > [1] > http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028710.html
