The control group (cgroup) pseudo filesystem is the key feature enabling resource quotas on containers deployed on Kubernetes. The cgroups filesystem is a Linux kernel feature and comes in one of three forms, depending on the hosts' configuration:
- cgroup v2, or unified hierarchy
- cgroup v1, or legacy hierarchy
- hybrid (basically cgroup v1, but some system services use cgroup v2).
The state of the art is cgroup v2. With the releases of Red Hat OpenShift 4.12 and Red Hat Enterprise Linux 9, which both feature cgroup v2, it becomes increasingly likely that OpenJDK 8 running in containers runs on a cgroup v2-enabled Linux kernel. Cgroup v1, the current predominant configuration, will become increasingly less frequent in practice as time moves forward.
OpenJDK 8u372: cgroup v1 and v2 support
With the release of OpenJDK 8u372 in April 2023, the cgroup v2 support patches present in later JDK releases have been backported to OpenJDK 8. 30 patches in total have been backported so as to bring this feature to OpenJDK 8u. It was added to OpenJDK 8u, a very mature and stable JDK release, under the enhancement exception rule of adapting to new hardware and operating environments.
Version 8u372 and later will detect the cgroup version in use, v1 or v2, on the host system. Once it detects the version, it looks up the set resource limits via the pseudo filesystem hierarchy and will size its internal resources accordingly. This will ensure that OpenJDK 8 will comply to the set resource limits of containers on cgroup v2 systems, a feature OpenJDK users have grown accustomed to since it was first brought to OpenJDK 8 with the 8u192 release.
How to see which cgroup version OpenJDK 8u detected
One easy way to see which cgroup version, if any, OpenJDK 8u detected is by using the
-XshowSettings:system Java launcher switch. Example:
[root@357fec96b37e /]# /opt/jdk8u372/bin/java -XshowSettings:system -version Operating System Metrics: Provider: cgroupv2 Effective CPU Count: 3 CPU Period: 100000us CPU Quota: 300000us CPU Shares: -1 List of Processors: N/A List of Effective Processors, 4 total: 0 1 2 3 List of Memory Nodes: N/A List of Available Memory Nodes, 1 total: 0 Memory Limit: 500.00M Memory Soft Limit: 0.00K Memory & Swap Limit: 500.00M openjdk version "1.8.0_372-beta" OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-beta-202303201451-b05) OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b05, mixed mode)
Another way is to use the
-XX:+UnlockDiagnosticVMOptions -XX:+PrintContainerInfo JVM switches in order to see the details of which files are being looked up internally:
[root@357fec96b37e /]# /opt/jdk8u372/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintContainerInfo -version OSContainer::init: Initializing Container Support Detected cgroups v2 unified hierarchy Path to /cpu.max is /sys/fs/cgroup//cpu.max Raw value for CPU quota is: 300000 CPU Quota is: 300000 Path to /cpu.max is /sys/fs/cgroup//cpu.max CPU Period is: 100000 Path to /cpu.weight is /sys/fs/cgroup//cpu.weight Raw value for CPU Shares is: 100 CPU Shares is: -1 CPU Quota count based on quota/period: 3 OSContainer::active_processor_count: 3 CgroupSubsystem::active_processor_count (cached): 3 total physical memory: 5033832448 Path to /memory.max is /sys/fs/cgroup//memory.max Raw value for memory limit is: 524288000 Memory Limit is: 524288000 total container memory: 524288000 total container memory: 524288000 CgroupSubsystem::active_processor_count (cached): 3 Path to /cpu.max is /sys/fs/cgroup//cpu.max Raw value for CPU quota is: 300000 CPU Quota is: 300000 Path to /cpu.max is /sys/fs/cgroup//cpu.max CPU Period is: 100000 Path to /cpu.weight is /sys/fs/cgroup//cpu.weight Raw value for CPU Shares is: 100 CPU Shares is: -1 CPU Quota count based on quota/period: 3 OSContainer::active_processor_count: 3 openjdk version "1.8.0_372-beta" OpenJDK Runtime Environment (Temurin)(build 1.8.0_372-beta-202303201451-b05) OpenJDK 64-Bit Server VM (Temurin)(build 25.372-b05, mixed mode)
OpenJDK 8u362 and older: cgroup v1 only
Older releases of OpenJDK 8u will only be able to detect cgroup v1 systems. Security considerations aside, it's highly encouraged to upgrade to a later release if you are running your containers on recent cloud infrastructure such as OpenShift 4.12. For example, for a 8u362 build of OpenJDK on a cgroup's v2 system, it would look like as if the container detection failed (i.e., no metrics):
$ ./jdk8u362-b09/bin/java -XshowSettings:system -version Operating System Metrics: No metrics available for this platform openjdk version "1.8.0_362" OpenJDK Runtime Environment (Temurin)(build 1.8.0_362-b09) OpenJDK 64-Bit Server VM (Temurin)(build 25.362-b09, mixed mode)
Onward to JDK 21
While it's important to support new computing environments in older JDK releases, the next OpenJDK LTS release, OpenJDK 21, is around the corner and is scheduled to be released in September 2023. JDK 21 includes many more improvements for a better container and cloud experience. So if you are thinking of writing new Java applications, consider targeting JDK 21, and perhaps using Quarkus for the best cloud native experience!
Looking for more resources? Explore all things Java on Red Hat Developer.