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