Here you go. https://bugs.openjdk.java.net/browse/JDK-8226575 <https://bugs.openjdk.java.net/browse/JDK-8226575>
Thanks, Bob. > On Jun 21, 2019, at 9:08 AM, Severin Gehwolf <sgehw...@redhat.com> wrote: > > Hi Bob, > > On Fri, 2019-06-21 at 08:56 -0400, Bob Vandette wrote: >>> On Jun 21, 2019, at 4:22 AM, Severin Gehwolf <sgehw...@redhat.com> wrote: >>> >>> Hi Bob, >>> >>> On Thu, 2019-06-20 at 10:16 -0400, Bob Vandette wrote: >>>> 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. >>>> >>>> It would be helpful if you feel this is important to add some votes >>>> to this issue. >>> >>> It seems strange that the getAvailableProcessors() returns the >>> container limit, while the memory limits are for the physical host. If >>> anything, shouldn't they agree (both physical host or both container >>> limits)? >>> >>> When I briefly looked into it initially it seems to be a side-effect of >>> what is being used by the JDK code implementation-wise. IIRC >>> getAvailableProcessors() uses a runtime call. Memory reporting has it's >>> own logic[1], thus not reporting the container limit. >>> >>> This seems weird from a consistency perspective. Thoughts? >>> >>> If I understand you correctly, you are arguing that container reporting >>> should go into its own MX bean. On the other hand, CPU reporting for >>> the OS MX bean is container aware already. That makes me believe we >>> should rather make this consistent before evaluating a new MX bean. >> >> You make a good point. I’ll split the enhancement and add a bug to fix the >> current MX Bean since this is pretty easy to do. > > Sounds great! Please let me know once the OS MX bean bug has been > created. I'll then assign it to myself and help Andrew through the > process of getting it fixed. > > Thanks, > Severin > >> Bob. >> >>> Thanks, >>> Severin >>> >>> [1] >>> http://hg.openjdk.java.net/jdk/jdk/file/1c242c2d037f/src/jdk.management/unix/native/libmanagement_ext/OperatingSystemImpl.c#l365 >>> >>> >>>> 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> >
