No way to disable Java Container Metrics
Laurence Cable
larry.cable at oracle.com
Fri Jul 24 22:59:54 UTC 2020
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 <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
>>
More information about the serviceability-dev
mailing list