No way to disable Java Container Metrics

[Bob Vandette]

> On Jul 27, 2020, at 11:32 AM, Severin Gehwolf <sgehwolf at 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.

Bob.


> 
>> 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
>>> 
>