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