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

[Erik Österlund]

On Tue, 9 Dec 2025 11:59:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

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

As a user of this API, I don't see what I would do about there being an error reading a limit, vs reading that there is a limit which does not do any actual limiting. In both cases I act as if there is no container limit I can use and fall back to looking st machine limits. Maybe it's a lack of imagination, but I don't know what else I'm supposed to do.

If complaining in a log or something is the answer, then I'd prefer such complaints to be inside of the implementation instead of having the user do that.

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

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