There is currently little to no coverage for the container detection code as part of substrate. It would be good to have basic coverage of the container detection code which changes PhysicalMemory.size()'s meaning when running in a container. Similarly there is no coverage for the various aspects for what Runtime.getRuntime().availableProcessors() returns for various settings when run in a container with limits applied. There are at least these combinations to consider for CPU:
--cpuset-cpus switch (i.e. CPU affinity)
--cpu-quota/--cpu-period (or --cpus) switches
A combination of the above plus -XX:ActiveProcessorCount switches.
I propose to write some tests using docker/podman to run a native image (built with -H:+UseContainerSupport, the default) inside a container with given limits expecting for the various sizings to take effect. What's more, those tests should match JFR events such as jdk.ContainerConfiguration from the JDK. That is, the JDK impl and the substrate impl, should not diverge.
Describe the issue
There is currently little to no coverage for the container detection code as part of substrate. It would be good to have basic coverage of the container detection code which changes
PhysicalMemory.size()
's meaning when running in a container. Similarly there is no coverage for the various aspects for whatRuntime.getRuntime().availableProcessors()
returns for various settings when run in a container with limits applied. There are at least these combinations to consider for CPU:--cpuset-cpus
switch (i.e. CPU affinity)--cpu-quota/--cpu-period
(or--cpus
) switches-XX:ActiveProcessorCount
switches.I propose to write some tests using
docker/podman
to run a native image (built with-H:+UseContainerSupport
, the default) inside a container with given limits expecting for the various sizings to take effect. What's more, those tests should match JFR events such asjdk.ContainerConfiguration
from the JDK. That is, the JDK impl and the substrate impl, should not diverge.