RFR: 8226575: OperatingSystemMXBean should be made container aware

[David Holmes]

Hi Severin, Andrew,

On 20/07/2019 2:07 am, Severin Gehwolf wrote:
> 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 :)

I've added a lengthy comment to the CSR. I don't think we can 
meaningfully try to retrofit this onto the existing MXbean and 
attempting to do so will just open a can worms when it comes to 
compatibility. A new MXbean that exposes the desired information for 
what is available to the VM may be a simpler path forward.

Cheers,
David
-----

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