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

[Casper Norrbin]

On Mon, 27 Oct 2025 08:40:03 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

>>> is that alternative container implementation really implementing a container, or a virtual machine?
>> 
>> You would have to define what you mean by "container" and "virtual machine".  Isolating CPU usage ala tasksets seems a natural partitioning approach for a "container" environment to me.
>
>> > is that alternative container implementation really implementing a container, or a virtual machine?
>> 
>> You would have to define what you mean by "container" and "virtual machine". Isolating CPU usage ala tasksets seems a natural partitioning approach for a "container" environment to me.
> 
> Not sure if me defining containers and virtual machines will take this discussion further. But for what it's worth, it is becoming popular to run a "MicroVM" instead of a container (cf. firecracker, new mac OS "containers" that are micro VMs). What it has in common with containers is that it is lightweight and starts fast. But it has dedicated hardware and you can't see the host hardware availability from it. So a perhaps more relevant question is:
> 1) How are these modelled today? AFAIK: they are not detected as containers.
> 2) How can we model these today? AFAIK: we can't get resource usage information from the host.
> 3) How do we want to model these today? IMO: not as containers. They quack more like virtual machines than containers and there is no obvious benefit of knowing about the world outside of the micro VM.
> 
> Regardless of these thoughts around micro VMs, I don't know if we will get far with trying to predict whether this API will fit well for a future hypothetical container system that works differently, or not. I'd vote for crossing that bridge when we get there instead, if we eventually find out then, that it could do with being updated. Does that sound good?

After some offline discussion with @fisk , I've pushed a couple minor changes:
- First, when there is no memory limit, internal functions currently set the limit to a predefined `value_unlimited`. However, for callers of the public API, returning this value is less helpful, they only need to know whether a limit exists. So now, if the memory limit is unlimited, we simply return `false` to indicate there is no enforced limit.
- Second, I've removed the asserts for `is_containerized()`. There's nothing actually preventing someone from checking cgroup values directly, so we shouldn't block this with an assert. Also, since being "containerized" is partly defined as having a resource limit set, it seems redundant to require checking for a limit before accessing its value.

 
@dholmes-ora, could you please take another look at these changes? I hope I've addressed some of the earlier pain points and that we can move closer to getting this finalized.

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

PR Comment: https://git.openjdk.org/jdk/pull/27646#issuecomment-3607030533