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