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

David Holmes dholmes at openjdk.org
Tue Oct 7 01:55:47 UTC 2025


On Mon, 6 Oct 2025 14:48:29 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 incrementally with one additional commit since the last revision:
> 
>   Fixed print type

What is a "machine" here? Historically we have misused "physical" to mean what does a bare-metal OS report on a bare-metal piece of hardware. But that became inaccurate decades ago once virtualization/hypervisors arrived. So we've adjusted API's (e.g. MXBeans) to report whatever the "operating system" reports. The problem there is some things the operating system reports take into account the presence of containers, and others do not. This has always been a problem with these container environments - they should be invisible to software but they are not.

> To support this, an os::is_containerized function should also be added.

For a long time this was an impossible question to answer accurately  -  we could query whether cgroups were configured on a system but we couldn't ask if the JVM process was running under any cgroup constraints - has that changed?

I would like to get a better idea of what kinds of "machine" information we need to query and how it will be used. I mean, how does it help to know a "machine" has 256 processors if the various software layers only make 16 available to you?

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

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


More information about the hotspot-dev mailing list