Parallel Garbage Collector

Parallel Garbage Collector (Parallel GC) is a Java GC algorithm designed to speed up memory cleaning by using multiple threads. Unlike Serial GC, which pauses everything and works single-threaded, Parallel GC divides the work across threads to shorten pause times. It focuses on high throughput, making it suitable for apps that can tolerate occasional pauses but require fast processing.

Parallel Garbage Collector

How Parallel GC works (Step by Step)?

  1. Initial Mark: First, it does a short pause to mark objects reachable from roots (like active threads or static fields).
  2. Parallel Mark: Then, multiple GC threads mark all live objects together. Because of parallel work, it finishes faster.
  3. Remark: Next, it briefly pauses again to mark objects created during the earlier mark phase.
  4. Parallel Sweep & Compact: After marking, GC threads remove unused objects and compact the heap to reduce fragmentation.
  5. Pointer Reset: Finally, it resets pointers to free memory in one go, ready for new objects.

When to use Parallel GC?

Use Parallel GC when:

  • You run on a multi-core machine (2 or more cores).
  • You need high throughput, even if occasional pauses occur.
  • Your heap is medium to large in size.
  • You can accept moderate pause times (up to seconds).

Thus, it fits batch processing, data analysis, or server apps with high throughput.

How to enable Parallel GC?

Enable it with this JVM option:

-XX:+UseParallelGC

Usually, JVM uses it by default on server-class machines.

Tuning Parallel GC

Here are the key tuning options:

  • -XX:ParallelGCThreads=<N>
    Set the number of GC threads. By default, JVM picks a fraction of CPU cores (e.g., ~5/8 if >8 cores)
  • -XX:MaxGCPauseMillis=<ms>
    Hint for max pause time. JVM adapts generation sizes to meet it
  • -XX:GCTimeRatio=<N>
    Defines GC time vs. app time as 1/(1+N). The default is 1% GC, 99% app time
  • -Xms/Xmx
    Set minimum and maximum heap sizes. Matching them avoids resizing pauses
  • Generation size adjustments:
    It grows and shrinks young/old generations to meet goals

Advantages of Parallel GC

  • It reduces pause time by using multiple threads.
  • It offers high throughput, which suits busy apps.
  • JVM auto-tunes generations to meet pause and throughput goals.

Limitations of Parallel GC

  • It still causes stop-the-world pauses, though shorter than Serial GC.
  • It may cause memory fragmentation, especially with many threads marking promotions
  • It uses more CPU, so on single-core machines, Serial GC might work better.
  • It lacks low-pause-time guarantees needed by real-time or interactive apps.

Additional Insights

  • Logging Parallel GC events helps track performance and tuning needs
  • Configuring ParallelGCThreads helps balance speed vs. fragmentation.
  • Server-class JVMs often enable Parallel GC by default, showing its suitability for multi-core environments.

Conclusion

In summary, Parallel GC:

  • Uses multiple threads to clear memory fast
  • Balances between throughput and pause time
  • Offers tunable options like thread count, pause target, and heap sizing
  • Works well for server-side, high-load apps on multi-core machines

However, if you require very low-latency (interactive) behavior, consider alternative collectors such as G1 or CMS.


You may be interested: