Hi Andrew, I am aware of the limitations of the OperatingSystemMXBean and was hoping to address these limitations during the implementation of https://bugs.openjdk.java.net/browse/JDK-8199944 <https://bugs.openjdk.java.net/browse/JDK-8199944>.
It would be helpful if you feel this is important to add some votes to this issue. Bob. > On Jun 20, 2019, at 9:43 AM, Andrew Azores <aazo...@redhat.com> wrote: > > 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 > <jdk-osmxbean-container-memory-test-01.patch>
