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

Casper Norrbin cnorrbin at openjdk.org
Thu Dec 4 09:42:14 UTC 2025


On Wed, 3 Dec 2025 15:19:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> 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 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`.

With no soft limit set in cgroup v2, the corresponding `memory.low` is set to 0 by default. However, looking at this for cgroup v1, it could instead be a very high number, so we return `value_unlimited`. We should probably change one so both behave the same.

Here it makes sense to check for both `0` and `value_unlimited` instead of just `0`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27646#discussion_r2588267446


More information about the hotspot-dev mailing list