RFC: Disable Java container metrics via some means in 8u?

[Severin Gehwolf]

Hi,

I'm currently working on a backport of:

JDK-8226575: OperatingSystemMXBean should be made container aware

For this to work, the Java subsystem for container metrics is being
backported: JDK-8203357: Container Metrics.

The thing is, with the hotspot changes one can disable container
detection via a flag, -XX:-UseContainerSupport. The same is not the
case in the container metrics case. It cannot be disabled if backported
as-is. This also means that there wouldn't be a work-around for cases
where the container metrics detection is wrong. What's more, it being
"wrong" might be exacerbated by the fact that container metrics have
slighly different semantics than hotspot. For hotspot all 4 controllers
 (cpu, cpuacct, memory, cpuset) need to be present for the container
detection to kick in. For Java metrics, it's sufficient for any one of
the 5 controllers (cpu, cpuacct, memory, cpuset, blkio) to be present
for it to return non-null. That, and some coding in the metrics code
which turns missing files into 0's instead of some other known-to-be-
invalid-value. That in turn can result in regressions.

There've been reports about this issue happening outside a container on
Linux already:

http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012183.html

The Proposal:

Ideally, use -XX:UseContainerSupport flag. Not sure if there is a way
to access that hotspot flag without a native call to the JVM. I'm not
sure if I like that.

As an alternative to the call-into-JVM-approach, introduce a separate
switch, say -Djdk.internal.platform.metrics=false, which would disable
the container metrics. Hence, all usages of it would return null, thus,
falling back to the old non-container code. In the
OperatingSystemMXBean case it would mean to get back where it was
before the new feature.

Thoughts? Opinions?

Thank you!

Cheers,
Severin