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

[David Holmes]

On Tue, 9 Dec 2025 10:01:50 GMT, Casper Norrbin <cnorrbin at openjdk.org> wrote:

>>> However, if the function returns false, there is no guarantee that the out-parameter is untouched
>> 
>> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.
>> 
>>> It doesn't make sense to return true if there is no limit
>> 
>> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information.  The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".
>
>> I think that should be guaranteed. This is our API we can make it as strict as we desire. If I have preset a sentinel value and the op fails then I should be able to rely on my sentinel remaining intact.
> 
> From the feedback I've changed so returning `false` now doesn't change the value, so we keep that assumption.
> 
>> But now you are overloading the use of the return value. It was intended to reflect success or failure, not provide semantic information. The higher-level function can choose to return true when there is a limit and false when there is not, but it can't also mean "or an error occurred".
> 
> I'd argue that in this context, we fail (and should return `false`) when we can't find a limit. When a caller asks the generic `Container` layer for a limit and none is found, "no limit" isn't a meaningful limit to report. Not finding a limit is the failure here, not being unable to read a cgroup file.

The way you would respond to an actual failure to read a cgroup file would be completely different to how you respond to there being no limit. Defining a sentinel value to represent "no limit" would make perfect sense for this API in my opinion.

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

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