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

[Severin Gehwolf]

On Thu, 25 Aug 2022 17:31:46 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > The gist of this patch is code like this:
> > ```
> > jlong CgroupV1Subsystem::read_memory_limit_in_bytes() {
> >   GET_CONTAINER_INFO(julong, _memory->controller(), "/memory.limit_in_bytes",
> >                      "Memory Limit is: " JULONG_FORMAT, JULONG_FORMAT, memlimit);
> >   if (memlimit >= _unlimited_memory) {
> >    ...
> >   } else {
> >     return (jlong)memlimit;
> >   }
> > ```
> > 
> > ... might return arbitrary large values on some systems (note that `_unlimited_memory = (LONG_MAX / os::vm_page_size()) * os::vm_page_size()` which can be fairly large; we've observed systems where the cgroup interface files have `92233720365056` whereas the `_unlimited_memory` value was `9223372036854771712`). That on a system with 8GB physical memory.
> 
> Okay, makes sense to fix it. But why not return "invalid" or "not set" and give the caller the responsibility to deal with it?

Because you don't know? There is nothing in the cg1 interface files which would tell you that. So you have to come up with a heuristic for "unlimited". For cg2 you have `max`, cg1 just contains random large numbers (if unset).

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

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