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