On 7/24/20 12:21 PM, 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.
+1 makes sense to me.
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.
Do you think of JMX accesses as of sufficiently high frequency such that
JNI overhead
would become a serious issue?
Having the functionality in the VM
makes it easier to add JFR events.
this is a plus
Having a pure Java implementation makes it
easier to support the OS MBeans.
as of course is this!!! :)
The maintenance of supporting both implementations
is a bit of a pain.
but probably not 2x right?
Assuming no one has the time or desire to migrate the logic to the VM and
provide
Java wrapper logic,
Bob, is this something you think worth recording as an ER for future
resolution?
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.
agreed
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
