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

[Casper Norrbin]

On Thu, 4 Dec 2025 08:37:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> I don't see a specification for any of these bool-returning functions with out-parameters (whether already existing or new here) so I'm not quite sure how to read a lot of them. Does returning true mean asking about a limit was successful, or that it was successful and there is a limit? Do the low-level functions have the same behaviour as the higher-level ones?
>
> This started with:
> https://bugs.openjdk.org/browse/JDK-8357086
> 
> They should have the same meaning throughout. Returning `true` means the passed in reference has been set to a value. In the container case it might be `value_unlimited` (for example an interface file has value `max`). So if the desire is to return `false` for unlimited, then this needs to be handled on top.

>From my perspective, returning `true` from one of these functions means that the out-parameter is set to a valid, meaningful value and can be used safely by the caller. However, if the function returns `false`, there is no guarantee that the out-parameter is untouched, so relying on its previous value is unsafe. Your example is to me is a bad pattern and is brittle at best.

There is a distinction between `OSContainer::memory_limit_in_bytes` (which always fetches and returns the cgroup, including `value_unlimited` for no limit) and the higher-level `os::Container::memory_limit`, which is about determining whether there is an effective limit at all, and if so, what it is. It doesn't make sense to return `true` if there is no limit, since there wouldn't be a meaningful value to provide. `value_unlimited` is just an internal constant and not helpful for callers.

That said, I can update so we don't pass through the out-parameter so that we don't modify it when returning `false`, to be somewhat more consistent. But I still believe we should return `false` when no limit is set.

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

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