RFR: 8226575: OperatingSystemMXBean should be made container aware

[Severin Gehwolf]

Hi Andrew,

On Wed, 2019-07-17 at 14:45 -0400, 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/

src/jdk.management/share/classes/module-info.java

I don't think you need to explicitly require java.base. Everything
depends on java.base. Is there a specific reason why that was needed?

I've noticed that this test fails with your patch:

FAILED: com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java

Fails with:
java.lang.RuntimeException: getSystemCpuLoad() returns 173995.48501979 which is not in the [0.0,1.0] interval
	at GetSystemCpuLoad.main(GetSystemCpuLoad.java:43)

This makes me wonder what the effect of this patch is on Linux
*outside* a container. Have you verified that Metric values correspond
to what whas previously returned via native methods? Could you verify,
please and tell us the before/after values? Thanks!

I wonder if we should split the OperatingSystemMXBean tests into it's
own (and not piggy-back on
TestCPUAwareness.java/TestMemoryAwareness.java). Have you considered
that?

Thanks,
Severin

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