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

[Severin Gehwolf]

On Wed, 3 Dec 2025 13:55:06 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>> Hi everyone,
>> 
>> The current `os::` layer on Linux hides whether the JVM is running inside a container or not. When running inside a container, we replace machine values with container values where applicable, without telling the user of these methods. For most use cases, this is fine, users only care about the returned value. But for other use cases, where the value originated is important. Two examples:
>> 
>> - A user might need the physical cpu count of the machine, but `os::active_processor_count()` only returns the limited container value, which also represents something slightly different.
>> - A user might want the container memory limit and the physical RAM size, but `os::physical_memory()` only gives one number.
>> 
>> To solve this, every function that mixed container/machine values now has to explicit variants, prefixed with `machine_` and `container_`. These use the bool return + out-parameter interface, with the container functions only working on Linux. The original methods remain and continue to return the same mixed values.
>> 
>> In addition, container-specific accessors for the memory soft limit and the memory throttle limit have been added, as these values matter when running in a containerized environment.
>> 
>> `OSContainer::active_processor_count()` has also been changed to return `double` instead of `int`. The previous implementation rounded the quota/period ratio up to produce an integer for `os::active_processor_count()`. Now, when the value is requested directly from the new container API it makes more sense to preserve this fraction rather than rounding it up. We can thus keep the exact value for those that want it, then round it up to keep the same behavior in `os::active_processor_count()`.
>> 
>> Testing:
>> - Oracle tiers 1-5
>> - Container tests on cgroup v1 and v2 hosts.
>
> Casper Norrbin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - return false when no limit + removed unneeded asserts
>  - Merge branch 'master' into separate-container-machine-values
>  - Merge branch 'master' into separate-container-machine-values
>  - Merge branch 'master' into separate-container-machine-values
>  - Move methods to Machine/Container inner classes + clarifying documentation
>  - Merge branch 'master' into separate-container-machine-values
>  - Fixed print type
>  - separate-machine-container-functions

src/hotspot/os/linux/os_linux.cpp line 222:

> 220:     return true;
> 221:   }
> 222:   return false;

Assume this usage:

physical_memory_size mem_limit = 0;
if (!os::Container::memory_limit(mem_limit)) {
  // assume mem_limit == 0;
}


The general contract for cases where a function returned `false` (i.e. error) is that the passed in reference remains untouched. This seems to violate that contract. `value` could change from whatever the initial value was to `value_unlimited` and return `false`.

src/hotspot/os/linux/os_linux.cpp line 226:

> 224: 
> 225: bool os::Container::memory_soft_limit(physical_memory_size_type& value) {
> 226:   if (OSContainer::memory_soft_limit_in_bytes(value) && value != 0) {

Why the `value != 0` check? Shouldn't this check for `value_unlimited` as is done for other `limit` functions? Same issue applies in the theoretical case where `0` is being read. The function returns `false`, but the initial `value` might have not been `0`.

src/hotspot/os/linux/os_linux.cpp line 236:

> 234:     return true;
> 235:   }
> 236:   return false;

Same here with the changed `value` when `value_unlimited` is being read, and function returning `false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585526251
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585539114
PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2585548526