In https://github.com/openjdk/jdk/pull/9880, we had a discussion about the organisation of the layers of abstraction internal to hotspot implementing Linux cgroups support. In particular these two comments by Thomas Stuefe illustrate the problem:

 * https://github.com/openjdk/jdk/pull/9880#issuecomment-1227566514
 * https://github.com/openjdk/jdk/pull/9880#issuecomment-1228339437

What follows is my summary, any deviations or mistakes are my own.

The entry-points to the code we are concerned with are `os::physical_memory()` and `os::available_memory()`.

Underneath those, in the Linux code, we have `os::Linux` providing `physical_memory()` and `available_memory()`, and a separate set of classes for cgroups information, fronted by `OSContainer`.

For total memory, the Linux implementation of `os::physical_memory()` calls into both the `Linux` and `OSContainer` classes to determine the answer. However, `OSContainer` also calls back into the `Linux` class.

For available memory, the Linux implementation of `os::available_memory()` calls solely to `Linux::available_memory()`, which in turn calls `OSContainer`. Again, `OSContainer` calls back into the `Linux` class.

The inconsistency between those two approaches, combined with the layering violation of `OSContainer` calling to `Linux`, serves to make this hard to follow.

Relatedly, `OSContainer` is implemented in terms of a family of other classes: `CgroupSubsystem`, `CgroupV1Subsystem` and `CgroupV2Subsystem`. Perhaps `OSContainer` and `CgroupSubsystem` could be merged to simplify this.