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

[Severin Gehwolf]

On Thu, 18 Aug 2022 02:54:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Good questions. I think the answer is that the cgroups values might change during VMs lifetime. I never understood why that was a goal to support, but fine. It's possible to do via docker so I guess that's why. As to the question why bother doing it in init too? I don't know. Maybe @dholmes-ora remembers?
>> 
>> Perhaps the better fix would be to fix the values in `OSContainer::memory_limit_in_bytes()`, instead of at all call-sites. It appears `os::Linux::available_memory()` would need similar treatment.
>
> @jerboaa I don't  sorry. My involvement with the container support was only peripheral.

Looking at the [original changeset](https://hg.openjdk.java.net/jdk/jdk/rev/7f22774a5f42#l11.30) for this it appears the only reason for it is to account for `-XX:+AggressiveHeap` and setting related flags. As to why the hook in `os::physical_memory()` isn't sufficient I'm at a loss. The original review here https://mail.openjdk.org/pipermail/hotspot-dev/2017-October/028635.html suggests that there was supposed to be some support for interleaving os initialization and arguments processing, but I don't see it. To be safe, I'd just leave this as it is for this patch and potentially clean this up as a separate bug. Thoughts?

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

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