RFR: 8292083: Detected container memory limit may exceed physical machine memory [v4]

[Jonathan Dowland]

On Wed, 17 Aug 2022 14:34:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Could we give this test a better name? How about `testContainerMemExceedsPhysical`?
>> 
>> Of course - that name is good. 
>> 
>>>  Anyway, we could perhaps write a WhiteBox based one which asserts that the os::physical_memory() never exceeds the host memory. See WhiteBox.printOsInfo() for an example as to how that's done.
>> 
>> Do you mean as well as, or instead of, the `OperatingSystemMXBean` approach I've currently taken? (I'm aware it's a bit of a smell. I did test preliminary backports to 11u and 8u, and this is one area that isn't clean)
>> 
>> Looking at `printOsInfo`: is your suggestion to call that and inspect the output, or extend `WhiteBox` itself with a physical memory limit method? I lean towards the latter
>
>> > Anyway, we could perhaps write a WhiteBox based one which asserts that the os::physical_memory() never exceeds the host memory. See WhiteBox.printOsInfo() for an example as to how that's done.
>> 
>> Do you mean as well as, or instead of, the `OperatingSystemMXBean` approach I've currently taken? (I'm aware it's a bit of a smell. I did test preliminary backports to 11u and 8u, and this is one area that isn't clean)
> 
> Instead of. OperatingSystemMXBean itself would return the container value but depends on the Java lib code. A cleaner way would be to just use `WhiteBox.physicalMemory()` or some such.
>  
>> Looking at `printOsInfo`: is your suggestion to call that and inspect the output, or extend `WhiteBox` itself with a physical memory limit method? I lean towards the latter
> 
> The latter.

With the test as it stands now, there are two Java processes in question: the outer-most test runner (jtreg invoked), which is using OperatingSystemMXBean to establish the host system's real physical RAM. This Java process does not have WhiteBox loaded, I don't think. This process is not subject to a cgroups memory limitation, unless the invoker has set one.

The second java process is run within a docker container by the test, with memory constraints. This launches WhiteBox.

I could extend WhiteBox to report the real physical RAM size (`os::Linux::physical_memory`), but the inner process would simply use that to print, for the outer process to match in the logs. Simpler IMHO would be to add a trace log line reporting the physical RAM size. Neither approach resolves the use of OperatingSystemMXBean in the outer process.

(extending WhiteBox to report (`os::Linux::physical_memory`) also means importing "os_linux.hpp" in "whitebox.cpp", and moving that method from `protected` to `public`. The method we write also needs to be substantially IFDEF'd to Linux-only, and return an error value for everyone else.)

Doing that means we are not comparing the view of system RAM between the inner and outer processes, and instead relying entirely on what the inner process reports. Is that a problem?

-------------

PR: https://git.openjdk.org/jdk/pull/9880