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

[Erik Österlund]

On Fri, 24 Oct 2025 06:13:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Looking again, and ignoring some earlier comments by others that might have mislead me, what is being proposed is much closer to that than what I initially thought. What I wanted to avoid was having 3 variants of a given method when the original os:: form of that method isn't even well-defined today. But I am okay with a set of "machine/system" methods to ask queries that make sense for the "machine"; and a set of container ones that make sense for containers. (And the implementation of the os:: method can delegate to whichever provides the "right" answer.)

Yeah that sounds good.

> But to clarify my issue with the container notion of available processors ... you state:
> 
> > It exposes what number of processors, on average, the container is limited to run on.
> 
> Yes - but if I am asking how many processors are available I am doing so because I want to know how many threads it makes sense creating, so I know how many threads could potentially be executing in parallel at the same time. Using my example above that could be 50% of the physical cores or 100% depending on how the container decides to implement quotas. That fits in, I think, with the example Casper gave above:
> 
> > In latency-sensitive workloads we might burst onto all 16 cores for a short interval and still stay within the 2-cpu quota. At the moment, the JVM has no way to know that those extra 14 cores even exist, so it cannot make that optimization.
> 
> Indeed - but if you create 16 threads to take advantage of that and the container only actually gives you 2 cores for 100% of the time, then you have totally messed up. This notion of "average processors" does not help you size accordingly, nor does knowing the number of "machine" processors, if you don't know how the container operates. That is one assumption about the container implementation I was referring to. 

Right - the number of threads you want to use is different if you have a concurrent system, compared to a parallel system, when the container implementation shares cores across containers. With a long running parallel workload, you want to size your threads according to the container average, as you say, because you won't get more CPU than that anyway and you will only run into trouble blowing the limits. Conversely, with a concurrent workload such as a server, where the unit of work takes, say, 1 ms to execute, you are more likely to want to size the threads of your thread pool according to the machine limits. Any time a request comes in to a server and there are idle CPUs on the machine, you are better off making sure the cores are working to reduce latency, compared to just waiting around. Then other means (such as load balancing, provisioning more containers, etc) need to be used to control that the average CPU utilization does not get close to the container limits (or indeed mac
 hine limits), because that will send latencies into a roller coaster.

In other words, with a parallel workload you want to size the threads according to the container limits. With a concurrent workload you want to size according to the machine limits, but monitor that average CPU utilization both on the container and machine levels, do not get too close to their corresponding limits. And that is why we want to be able to be able to access both of them.

I guess your concern is about an alternative container implementation where the limits are strict and you get a single exclusive core that none of the other containers is allowed to use, not one core on average. Then you would not need to worry about the machine layer, due to the lack of sharing of hardware resources across containers. I think there is a philosophical question there: is that alternative container implementation really implementing a container, or a virtual machine? For all practical purposes, it seems to me like that would be running in a virtual machine with dedicated hardware that we happen to call a container. I suspect that should a container environment like that pop up, we might want to model it like a virtual machine and not like a container.

If we did model it like a container, then yes, I wouldn't want to look around at the completely orthogonal "machine" layer any longer, as I don't share hardware with any of the other "containers", and they don't share any of my hardware either. It would be a rather different situation.

> The other is that the container never defines cpusets, otherwise you have no way that I am aware of to actually determine there are 16 cores on the machine**. Maybe these are safe assumptions to make, but it would be nice if the underlying container subsystem could give you those answers directly based on how it does things (then you wouldn't need to query the "machine".)
> 
> ** If you assume no hot-swapping of CPUs then `sysconf(_SC_NPROCESSORS_ONLN)` could give you that answer.

I agree. :)

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

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