Basic GC Tuning
Although GC algorithms differ in the way they process the heap, they share basic configura-
tion parameters. In many cases, these basic configurations are all that is needed to run an ap-
Sizing the Heap
The first basic tuning for GC is the size of the application's heap. There are advanced tunings
that affect the size of the heap's generations; as a first step, this section will discuss setting
the overall heap size.
Like most performance issues, choosing a heap size is a matter of balance. If the heap is too
small, the program will spend too much time performing GC and not enough time perform-
ing application logic. But simply specifying a very large heap isn't necessarily the answer
either. The time spent in GC pauses is dependent on the size of the heap, so as the size of the
heap increases, the duration of those pauses also increases. The pauses will occur less fre-
quently, but their duration will make the overall performance lag.
A second danger arises when very large heaps are used. Computer operating systems use vir-
tual memory to manage the physical memory of the machine. A machine may have 8 GB of
physical RAM, but the OS will make it appear as if there is much more memory available.
The amount of virtual memory is subject to the OS configuration, but say the OS makes it
look like there is 16 GB of memory. The OS manages that by a process called swapping. (Or
paging, though there is also a technical difference between those two terms that isn't import-
ant for this discussion.) You can load programs that use up to 16 GB of memory, and the OS
will copy inactive portions of those programs to disk. When those memory areas are needed,
the OS will copy them from disk to RAM (usually it will first need to copy something from
RAM to disk to make room).
This process works well for a system running lots of different applications, since most of the
applications are not active at the same time. It does not work so well for Java applications. If
a Java program with a 12 GB heap is run on this system, the OS can handle it by keeping 8
GB of the heap in RAM and 4 GB on disk (that simplifies the actual situation a little, since
other programs will use part of RAM). The JVM won't know about this; the swapping is
transparently handled by the OS. Hence, the JVM will happily fill up all 12 GB of heap it has
been told to use. This causes a severe performance penalty as the OS swaps data from disk to
RAM (which is an expensive operation to begin with).