Skip to content

CAUTION: This site hosts draft documentation for the next release. For published content of the latest release, visit


Sets the number of threads that the garbage collector uses for parallel operations.


This option enforces a fixed thread count and cannot be used with the -XX:+AdaptiveGCThreading option, which enables the garbage collector to adjust the number of parallel threads based on heuristics. If you want to use -XX:+AdaptiveGCThreading, use -Xgcmaxthreads instead of -Xgcthreads.




The total number of GC threads is composed of one application thread with the remainder being dedicated GC threads. By default, the number is set to n-1, where n is the number of reported CPUs, up to a maximum of 64. Where SMT or hyperthreading is in place, the number of reported CPUs is larger than the number of physical CPUs. Likewise, where virtualization is in place, the number of reported CPUs is the number of virtual CPUs assigned to the operating system. To set it to a different number, for example 4, use -Xgcthreads4. The minimum valid value is 1, which disables parallel operations, at the cost of performance. No advantage is gained if you increase the number of threads to more than the default setting.

On systems running multiple VMs or in LPAR environments where multiple VMs can share the same physical CPUs, you might want to restrict the number of GC threads used by each VM. The restriction helps prevent the total number of parallel operation GC threads for all VMs exceeding the number of physical CPUs present, when multiple VMs perform garbage collection at the same time.

This option is directly mapped to the HotSpot option -XX:ParallelGCThreads and can be used with all Eclipse OpenJ9™ GC policies.