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

[Severin Gehwolf]

On Thu, 2020-07-23 at 16:12 +0200, Severin Gehwolf wrote:
> 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.

Here is a proof of concept patch for this:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/UseContainerSupport/01/
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8203357/UseContainerSupport/before-after.txt

Perhaps this should be added to jdk/jdk first and backported all the way to 8...

Thanks,
Severin

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