RFR: 8226575: OperatingSystemMXBean should be made container aware

[Mandy Chung]

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

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

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

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