The Serial Garbage Collector (GC) derives its name from performing all its work on a single thread. The Serial GC is the simplest of the garbage collectors available on OpenJDK; however, there are some use cases where it might be the best option. Let’s take a look at the Serial GC in this article.

Serial GC Basics

The Serial GC performs all GC work on a single thread, reducing overhead as there is no need to coordinate efforts between threads. This makes the Serial GC ideal for running on systems with a single processor and/or limited resources. The Serial GC, however, can still be a valid choice for applications on multi-processor machines as long as the dataset remains under 100MB.

The Serial GC can be explicitly enabled with the VM flag -XX:+UseSerialGC.

HotSpot Ergonomics

While in most environments, the default GC selected by HotSpot is the G1 GC, in some environments, HotSpot ergonomics will select Serial GC. The determination is based on (a) if only a single processor is available or (b) if available memory is less than 1792MB. To see which GC is being used, set the VM flag -Xlog:gc.

$ java -Xlog:gc -jar target/spring-petclinic-2.6.0-SNAPSHOT.jar 
[0.004s][info][gc] Using Serial
[0.866s][info][gc] GC(0) Pause Young

Tuning Serial GC

There are several options for tuning the Serial GC; a few key options are:

• -XX:MaxGCPauseMillis: This provides a hint to the GC that pause times should be less than the provided amount. No default value is set for this flag.

• -XX:GCTimeRatio: This sets the ratio for the time spent between performing GC work and application work. The default value is set at 1 to 99.

• -XX:+UseStringDeduplication: In JDK 18, String deduplication was ported from the G1 GC to Serial GC. Enabling string deduplication can reduce memory footprint by about 10% but could impact pause times.

Additional Reading

• Available Garbage Collectors

• HotSpot Ergonomics

Happy coding!