[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: No way to disable Java Container Metrics
From:       Severin Gehwolf <sgehwolf () redhat ! com>
Date:       2020-07-27 16:06:23
Message-ID: bd7b6bf9d9f0797256cb7008c855c793c2666119.camel () redhat ! com
[Download RAW message or body]

On Mon, 2020-07-27 at 11:52 -0400, Bob Vandette wrote:
> > On Jul 27, 2020, at 11:32 AM, Severin Gehwolf <sgehwolf@redhat.com> wrote:
> > 
> > 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.
> 
> That was intentional.  I wanted the VM to configure itself consistently.
> Either all needed value are present or revert to non container mode.
> For Metrics, I felt it was ok to report whatever is available.

Yes, I know. Thanks. What I meant to say was that it's another
consideration to take into account if at some point a JVM-only-impl +
Java wrapper approach would be taken.

Thanks,
Severin
> 
> 
> > > 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@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&pag \
> > > > e=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
> > > > 


[prev in list] [next in list] [prev in thread] [next in thread]