1. The four available GC algorithms take different approaches toward minimizing
the effect of GC on an application.
2. The serial collector makes sense (and is the default) when only one CPU is avail-
able and extra GC threads would interfere with the application.
3. The throughput collector is the default on other machines; it maximizes the total
throughput of an application but may subject individual operations to long pauses.
4. The CMS collector can concurrently collect the old generation while application
threads are running. If enough CPU is available for its background processing,
this can avoid full GC cycles for the application.
5. The G1 collector also concurrently collects the old generation while application
threads are running, potentially avoiding full GCs. Its design makes it less likely
to experience full GCs than CMS.
Choosing a GC Algorithm
The choice of a GC algorithm depends in part on what the application looks like, and in part
on the performance goals for the application.
The serial collector is best used only in those cases where the the application uses less than
100 MB. That allows the application to request a small heap, one that isn't going to be
helped by the parallel collections of the throughput collector, nor by the background collec-
tions of CMS or G1.
That sizing guideline limits the usefulness of the serial collector. Most programs will need to
choose between the throughput collector and a concurrent collector; that choice is most influ-
enced by the performance goals of the application.
An overview of this topic was discussed in Chapter 2 : there is a difference in measuring an
application's elapsed time, throughput, or average (or 90th%) response times.
GC algorithms and batch jobs
For batch jobs, the pauses introduced by the throughput collector—and particularly the
pauses of the full GC cycles—are a big concern. Each one adds a certain amount of elapsed
time to the overall execution time. If each full GC cycle takes 0.5 seconds and there are 20