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

[David Holmes]

On Thu, 9 Oct 2025 13:00:33 GMT, Casper Norrbin <cnorrbin 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.

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

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