RFR: 8367319: Add os interfaces to get machine and container values separately [v2]

[Casper Norrbin]

On Thu, 9 Oct 2025 02:45:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>Ignoring the name for now, I think having three sets of methods is confusing - how will anyone know whether they should be using `os::free_memory` or `os::machine_free_memory`? The former says nothing about containers.
>
>IIUC the problem you are trying to resolve is that some existing `os::xxx` return values that account for containers and you would like to know the non-container limits. Does that happen often enough that we need 3 complete sets of API method's, or can we augment the problematic methods with a default parameter `bool ignoreContainers = false` so you can ask for the non-container version?

The goal isn't just to expose some os values when we happen to be running in a container, it's to make both numbers, the OS view and the cgroup limit accessible at the same time. Each has its own use-cases, and a single method with a default `bool ignoreContainers = ` doesn't really solve that.

To me it seems that the issue is really about clarity and confusion. While having 3 sets of APIs could be a lot, it is needed if we want to keep current behaviour and still allow access to the values separately. A solution to help with clarity could be:

os::free_memory() -> Default combined value for those that don't care where the value originated.
os::Machine::free_memory() - > For those that want the machine/os value.
os::Container::free_memory() -> For those that want the container value.
``` 
This separates the APIs into different classes, and each class could have accompanied text to explain its use. This makes the top level `os::free_memory()` the obvious default to use for most use cases that don't care if we are running in a container or not, while allowing container aware code that does care to get a more detailed view for the container view and machine view specifically.

>By the way it keeps getting mentioned that only Linux has container support, but we have started augmenting some of the Windows `os::xxx` functions to account for Windows Jobs (which can restrict available resources similarly to containers).

Currently, our container logic is linked to the Linux cgroup model, so when the code asks "am I in a container?" it really means "am I running under cgroups?". With the API split I'm proposing, that tight coupling disappears. cgroup support would simply be one of the platform-specific implementations of `Container::`, not the definition of a container.  That would make it easier to expand on Windows Job Objects (or any other resource-constraining framework) later on.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3385762961