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

[Severin Gehwolf]

On Mon, 22 Aug 2022 11:13:13 GMT, Jonathan Dowland <jdowland at openjdk.org> wrote:

>> src/hotspot/os/linux/osContainer_linux.cpp line 65:
>> 
>>> 63:   // We need to update the amount of physical memory now that
>>> 64:   // cgroup subsystem files have been processed.
>>> 65:   if ((mem_limit = cgroup_subsystem->memory_limit_in_bytes()) > 0) {
>> 
>> I'm concerned that this removal of the cgroup lookup re-introduces part of https://bugs.openjdk.org/browse/JDK-8232207
>> 
>> Without this call in early init we could potentially lose some of the caching effects we previously had.
>
> Hi Severin, thanks for your comment. As I understand [/JDK-8232207](https://bugs.openjdk.org/browse/JDK-8232207), a 20ms delay cache was added to `OSContainer::memory_limit_in_bytes`, and `OSContainer::init` called that routine, starting the 20ms timer. Any routines also calling `OSContainer::memory_limit_in_bytes` within 20ms of `OSContainer::init` would benefit from the caching.
> 
> This PR removes that cache seeding in `OSContainer::init`, so any caller to `OSContainer::memory_limit_in_bytes` within 20ms of `init` will indeed be slower. But that caller will seed the cache, so subsequent calls (within 20ms) will be unaffected. And, we're just moving the initial delay from `OSContainer::init` to the next caller: overall the delay will be the same.
> 
> Furthermore, in the event that there wasn't another caller to `memory_limit_in_bytes` within 20ms of `OSContainer::init`, the PR will speed things up, as prior, the cache is being seeded unnecessarily.
> 
> I am happy to try and do some performance comparisons if required.

With my proposed change (or something similar) in `os::Linux::available_memory()` this should be OK again. Note that `available_memory()` is being called frequently from the compile broker.

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

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