The OpenJDK hotspot container detection code assumes the following cgroup controllers as required: cpu, cpuset, cpuacct, memory. If one of those controllers are not available, or not enabled at the kernel level, the container detection code fails and falls back to host-only resource limits.

This is problematic on some systems, like Fedora 41, which don't have the cpuset controller enabled by default any more. File /proc/cgroups file doesn't list the controller as enabled. Example:

$ cat /proc/cgroups
#subsys_name hierarchy num_cgroups enabled
cpu 0 357 1
cpuacct 0 357 1
blkio 0 357 1
memory 0 357 1
devices 0 357 1
freezer 0 357 1
net_cls 0 357 1
perf_event 0 357 1
net_prio 0 357 1
hugetlb 0 357 1
pids 0 357 1
rdma 0 357 1
misc 0 357 1

I.e. there is no cpuset controller. This results in this output when container detection tracing is turned on:

$ ./bin/java -Xlog:os+container=trace --version
[0.000s][trace][os,container] OSContainer::init: Initializing Container Support
[0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.000s][debug][os,container] controller cpu is not enabled
[ ]
[0.000s][debug][os,container] One or more required controllers disabled at kernel level.
openjdk 25-internal 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)

There is a secondary bug which incorrectly maps the 'cpuset' controller to the 'cpu' one in the log output. Fixing that bug results in:

$ ./bin/java -Xlog:os+container=trace --version
[0.001s][trace][os,container] OSContainer::init: Initializing Container Support
[0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.001s][debug][os,container] controller cpuset is not enabled
[ ]
[0.001s][debug][os,container] One or more required controllers disabled at kernel level.
openjdk 25-internal 2025-09-16
OpenJDK Runtime Environment (build 25-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (build 25-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)

With all that said, the cpuset controller isn't really that essential. os::Linux::active_processor_count() uses sched_getaffinity() which in-turn figures out the cpuset setting. Thus, it's only reporting code that actually uses the cpuset controller interface files. This suggests that this controller can be made optional and improve automatic detection code on more systems.