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/ [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, -- Andrew Azores Software Engineer, OpenJDK Team Red Hat
