Why Does ParallelGCThreads Show 38 on a 4‑Core Container? Uncovering JVM Container Awareness

Background

The JVM flag ParallelGCThreads controls the number of parallel GC threads. In JDK 8 the default is:

If the CPU core count is ≤ 8, the GC thread count equals the number of cores.

If the core count > 8, the first 8 cores each get one GC thread and the remaining cores share 5 GC threads per 8 cores.

This logic assumes the JVM can see the actual CPU count of the host.

Issue in Containers

When running a simple program that sleeps for 1000 seconds inside a container limited to 4 CPU cores, the JVM reported ParallelGCThreads=38, indicating it ignored the container’s CPU quota.

JDK 8u144 Behavior

Using JDK 8u144 the following commands were executed:

./jdk1.8.0_144/bin/java -XX:+UseG1GC -XX:+ParallelRefProcEnabled Main

Then the GC thread count was checked:

$ jstack $pid | grep 'Parallel GC Threads' | wc -l
38

Printing the flag confirmed the same value:

$ ./jdk1.8.0_144/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep ParallelGCThreads
uintx ParallelGCThreads          =38                     {product}

Thus JDK 8u144 cannot read container resource limits.

JDK 8u191 Fix

Starting with JDK 8u191, the JVM detects container quotas. Running the identical program yields:

./jre1.8.0_191/bin/java -XX:+UseG1GC -XX:+ParallelRefProcEnabled Main

$ jstack $pid | grep 'Parallel GC Threads' | wc -l
4

And the flag shows the correct value:

$ ./jre1.8.0_191/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version | grep ParallelGCThreads
uintx ParallelGCThreads         =4                   {product}

JDK 8u191 also introduces the PrintContainerInfo flag, which prints detailed container metrics such as memory limit, CPU quota, period, and shares.

$ ./jre1.8.0_191/bin/java -XX:+UnlockDiagnosticVMOptions -XX:+PrintContainerInfo -version
OSContainer::init: Initializing Container Support
Path to /memory.limit_in_bytes is /sys/fs/cgroup/memory/memory.limit_in_bytes
Memory Limit is: 10737418240
Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
CPU Quota is: 400000
Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
CPU Period is: 100000
CPU Quota count based on quota/period: 4
…

Reading Container Limits Directly

The container’s cgroup files can be inspected manually:

$ cat /proc/mounts | grep -E -w '(cpu|memory)'
cgroup /sys/fs/cgroup/memory cgroup ro,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup ro,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0

Memory limit:

$ cat /sys/fs/cgroup/memory/memory.limit_in_bytes
10737418240

CPU quota and period:

$ cat /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
100000
$ cat /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
400000

From these values, the available CPU cores are calculated as quota / period = 4. The cpu.shares file (value 681) represents relative CPU weight but cannot be directly converted to core count.

$ cat /sys/fs/cgroup/cpu,cpuacct/cpu.shares
681

Conclusion

To obtain correct GC thread counts and container resource awareness, use JDK 8u191 or newer (or any later JDK). Older releases such as JDK 8u144 ignore cgroup limits, leading to inflated ParallelGCThreads values.