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

[Jonathan Dowland]

On Tue, 23 Aug 2022 09:58:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jonathan Dowland has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Avoid memory_usage_in_bytes when unconstrained
>>   
>>   Thanks to Severin for the suggestion. When there is no memory limit
>>   in place, avoid calling OSContainer::memory_usage_in_bytes, instead
>>   preferring the non-container sysinfo approach.
>
> src/hotspot/os/linux/os_linux.cpp line 199:
> 
>> 197:     jlong mem_limit, mem_usage, host_mem;
>> 198:     host_mem = Linux::physical_memory();
>> 199:     mem_limit = OSContainer::memory_limit_in_bytes();
> 
> With your latest changes in `cgroupV1Subsystem_linux.cpp` `mem_limit` would only exceed `host_mem` on cg2 with a memory limit specified `> host_mem` (very unlikely). Now we only do the gymnastics here to correct this situation. Instead, we could do it for both v1 and v2 in [CgroupSubsystem::memory_limit_in_bytes()](https://github.com/openjdk/jdk/blob/cf0067741249cc3260b1d220769dac408b614f22/src/hotspot/os/linux/cgroupSubsystem_linux.cpp#L525).
> 
> I'm not a big fan of this hybrid approach: correct cg1 values in `cgroupV1Subsystem_linux.cpp` and cg2 values in `os_linux`. My strong preference would be to do this in `CgroupSubsystem` code and keep `os_linux` code simpler.

Thanks for explaining your opinion so clearly (here and on IRC). I've taken your advice and moved the sanity checking to `CgroupSubsystem` in bc493c20ba2cd0cd4044e4aa2839abd8589c403a. I think this looks and functions much better now.

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

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