No way to disable Java Container Metrics
Severin Gehwolf
sgehwolf at redhat.com
Mon Jul 27 15:32:54 UTC 2020
Hi Bob,
On Fri, 2020-07-24 at 15:21 -0400, Bob Vandette wrote:
> I’ve been monitoring the discussion on your jdk8u alias and I can’t help wondering if
> my original decision to provide two different implementations of this container detection
> logic was the best way to go.
>
> I didn’t want to have an all Java implementation since the VM needs to initialize it’s
> memory and cpu sizing very early on prior to its ability to run Java code.
>
> If we put all of the logic in the VM, then we’d end up with a pretty wide interface to
> the VM and more overhead extracting values (due to JNI) although the Java logic
> typically ends up in native code anyway. Having the functionality in the VM
> makes it easier to add JFR events. Having a pure Java implementation makes it
> easier to support the OS MBeans. The maintenance of supporting both implementations
> is a bit of a pain.
Add to that that Java metrics return non-null for any controller it
finds. The JVM doesn't. Container support is turned on there only if
all cpu and memory controllers are found.
> Assuming no one has the time or desire to migrate the logic to the VM and provide
> Java wrapper logic, I’m ok with what you are proposing. It’s one step on the path.
> The VM support and the Java level support are really for two different consumers
> but I think it would be cleaner and less confusing to disable both on one flag rather
> than support two options.
OK, agreed. I've filed:
https://bugs.openjdk.java.net/browse/JDK-8250627
Thanks,
Severin
> Bob.
>
> > On Jul 24, 2020, at 12:13 PM, Severin Gehwolf <sgehwolf at redhat.com>
> > wrote:
> >
> > Hi,
> >
> > For hotspot one can disable container detection with a simple
> > switch:
> >
> > $ java -XX:-UseContainerSupport -Xlog:os+container=trace -version
> > [0.000s][trace][os,container] OSContainer::init: Initializing
> > Container Support
> > [0.000s][trace][os,container] Container Support not enabled
> > openjdk version "15-internal" 2020-09-15
> > OpenJDK Runtime Environment (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2)
> > OpenJDK 64-Bit Server VM (build 15-internal+0-
> > adhoc.sgehwolf.openjdk-head-2, mixed mode, sharing)
> >
> > The same cannot be achieved with the Java code,
> > jdk.internal.platform.Metrics.java and friends in the JDK. At the
> > time
> > Metrics were added the only consumer of them was the Java Launcher
> > via
> > -XshowSettings:system. This has changed with JDK-8226575:
> > OperatingSystemMXBean should be made container aware.
> >
> > It is known that in certain cases the container detection code will
> > detect for a system to be supposedly in a container where it
> > actually
> > isn't:
> > https://bugs.openjdk.java.net/browse/JDK-8227006?focusedCommentId=14275604&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14275604
> >
> > For hotspot there is a flag, to turn auto-detection off for exactly
> > the
> > case when heuristics are wrong: -XX:-UseContainerSupport. However,
> > this
> > flag has no effect on the Java metrics code. There is a risk that
> > on
> > some systems the auto-detection will be wrong and might cause
> > regressions.
> >
> > I propose to make the Java metrics code adhere to -XX:+/-
> > UseContainerSupport flag. Do you think this would be useful? If
> > yes,
> > I'll file a bug and propose a patch for it.
> >
> > Thoughts? Opinions?
> >
> > Thanks,
> > Severin
> >
More information about the core-libs-dev
mailing list