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

[Erik Österlund]

On Fri, 10 Oct 2025 04:38:19 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > 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,
> 
> I have to disagree with the basic premise there. `os::free_memory` has to be specified to return some notion of "free memory" and that will either have to account for, or not account for, containers. The caller can't "not care" because the caller has to know why they are asking for this and what they expect to get back.
> 
> I'm not convinced this API split is actually a good fit in general. The existing os::xxx API exposes some values based on a very old monolithic model of program execution: free-memory, available-memory, swap-space, available-processors. But they are not very well-defined concepts in modern compute environments. We've tried to map these to things that containers expose but there isn't always a clear way to do so - ref "active processors" when CPU quotas are involved. Even on the "machine" side it is far from clear e.g. what should "active processors" return for the "machine"? Your implementation will return sched_getaffinity values which accounts for cpu-sets that can come from the container environment - so that isn't really the "machine" value.
> 
> It might be clearer to just define specific methods for the things that are currently missing that you need to query, rather than trying to generalize the existing poorly-defined API. If you insist that three API's is better then I would like to see clear specifications for what each of the method variants actually returns.

@dholmes-ora I'm struggling to understand where you would like this to go. Do you want users to always explicitly decide whether they want to look through the container or not. In other words - are you against the idea of having an implicit API that gives you either the container or the "machine"? Or is it the word "machine" that you don't like?

Either way, this is what I need that I don't have access to today without breaking through the OS abstractions:
1) CPU quotas when running in a container.
2) The "machine" numbers when running in a container (which get overridden by container numbers).

Are you proposing we add new APIs for these things and leave everything else the way it is?

Just trying to understand what you mean so we can move forward with this.

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

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