OperatingSystemMXBean unaware of container memory limits

[Andrew Azores]

Hi all,

Apologies if this is not the most appropriate list, in which case
please direct me where to go.

I've noticed a surprising result from the
com.sun.management.OperatingSystemMXBean implementation when running in
a containerized (specifically, using Docker on Linux) environment. The
bean appears to be container-aware for processors, in that running with
Docker option `--cpus 1.0` for example, on a multicore system, will
cause both java.lang.Runtime#availableProcessors and
java.lang.management.OperatingSystemMXBean#getAvailableProcessors /
com.sun.management.OperatingSystemMXBean#getAvailableProcessors to
return 1. However, the Docker option `--memory 100M` (or any other
limit value) is not reflected in the value returned by
com.sun.management.OperatingSystemMXBeam#getTotalPhysicalMemorySize,
and instead the returned value is still the total physical memory of
the host machine - of which only a small portion may actually be
available to the "Operating System" of the JVM. Similarly for the
methods regarding free physical memory, total swap, and free swap.

I have attached a patch which adds a small reproducer to the existing
MemoryAwareness test.

This seems like a bug to me, since if the imposed container limit on
processors as a resource is included as part of the "Operating System"
resource reporting, then surely memory resources should be reported the
same way. As I said, I found the current behaviour quite surprising.

-- 
Andrew Azores
Software Engineer, OpenJDK Team
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk-osmxbean-container-memory-test-01.patch
Type: text/x-patch
Size: 5408 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20190620/24f89552/jdk-osmxbean-container-memory-test-01.patch>