[8u] RFR: 8226575: OperatingSystemMXBean should be made container aware

[Andrey Petushkov]

Hi Severin,

The code being backported seem to have a bug and will result in a
regression if
being integrated.

The problem is that, to my understanding it's legal that only some of known
controllers are mounted (at least man says they can be mounted
individually).
This creates a situation that Metrics gets "active" and populated with
some of
SubSystems, but not all. As a result OperatingSystemImpl considers
containerMetrics
available and uses it as a source. The SubSystem code is written the way
that it
returns 0 for any value if a respective subsystem is missing. At the
same time
OperatingSystemImpl typically uses >=0 as a sanity check of a value
returned from Metrics.
Effectively preventing from falling back to native implementation for
the actual value
and returning 0 instead of actual value

The problem actually exhibited by GetTotalPhysicalMemorySize test ran on
Raspbian Stretch
which happen to have cgroup fs but not /sys/fs/cgroup/memory

That's not the problem of a backport and of course should be discussed
with upstream
developers. It just happened that we've found it with a backport so
letting you know

Regards,
Andrey

On 17.07.2020 17:07, Severin Gehwolf wrote:
> Hi,
>
> Please review this OpenJDK 8u backport for OperatingSystemMXBean's
> container awareness which has been backported to Oracle JDK (parity
> bug). This backport depends on JDK-8203357[1] for Metrics.java which is
> being used in this patch.
>
> Changes as compared to the JDK 11 patch were:
>
>  * SubSystem.java: 8217338: [Containers] Improve systemd slice memory
>    limit support not being there => getLongValueMatchingLine() missing
>    => dropped
>  * OperatingSystemImpl.java: Introduced Java methods which internally
>    call the native methods. Renamed native methods to <oldmethod-name>0
>  * Tests were actually done to the hotspot code in later JDKs, thus,
>    for this backport the tests are in the hotspot portion of the webrev
>    (separate repo).
>  * Other than that, it's just the native bits which are in different
>    files in JDK 8.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8226575
> webrev: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8226575/jdk8/01/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8248804
>
> Testing: Included docker tests on Linux x86_64. jdk_management tests and
> tier 1 tests. No regressions noted.
>
> If somebody could test this on Windows/Mac, I'd appreciate it.
>
> Thanks,
> Severin
>
> [1] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-July/012164.html