The way I understood the bug report is a two fold approach, i.e. fix the os bean and *possibly* add a container one or extend it to add more data.
I agree with you and Andrew that the current OS Bean returns wrong information, this should be fixed in any case I think. Bob, do you have some design ideas to share regarding the new interface? I think this may be an interesting project to pick up, even for students wanting to write a thesis, as it seems time is a limiting factor here for you to work on that? Cheers, Mario On Fri 21. Jun 2019 at 10:53, 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. > > 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> > > > > > > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/
