Garbage Collection

Garbage collection (GC) is a mechanism provided by JVMs to reclaim heap memory space from objects which are taking up that memory but are not currently being used. The following parameters can be set to configure garbage collection.

Note: The terminology used in the following points assumes that you are familiar with the vocabulary of garbage collection. If you are not, consult some of the references listed in Information Resources .
  • -XX:+UseParallelGC  This command minimizes GC pauses by enabling parallel garbage collection for the section of the memory allotted to "new generation" space. The algorithm that it uses is tuned for heap sizes over 10 gigabytes, on multi-CPU machines. Issuing this command on such a multi-processor system can decrease the amount of time that it takes the JVM to complete a partial garbage collection cycle.
  • -XX:ParallelGCThreads  The Java UseParallelGC option uses as many garbage collector threads as there are processors/cores on the system. Use this option to control the number of threads used. For example:
    -XX:ParallelGCThreads=2
  • -XX:+DisableExplicitGC  Some applications make explicit GC calls thinking that it will make their application faster. In some cases this can lead to frequent unnecessary GC calls using up system resources. This Java option disables such explicit calls.
  • -XX:+UseParNewGC  This enables the parallel copying collector. Like the original copying collector, this is a stop-the-world collector. However this collector parallelizes the copying collection over multiple threads, which is more efficient than the original single-thread copying collector for multi-CPU machines (though not for single-CPU machines). This algorithm potentially speeds up young generation collection by a factor equal to the number of CPUs available, when compared to the original single-threaded copying collector.
  • -XX:SurvivorRatio  The SurvivorRatio parameter controls the size of the two survivor spaces. For example, -XX:SurvivorRatio=6 sets the ratio between each survivor space and eden to be 1:6, so that each survivor space will be one-sixth of the young generation. The default for Solaris is 32. If survivor spaces are too small, copying collection overflows directly into the old generation. If survivor spaces are too large, they will be empty. At each GC, the JVM determines the number of times that an object can be copied before it is tenured, called the tenure threshold. This threshold is chosen to keep the survivor space half full.
  • -XX:MaxTenuringThreshold  Allows short-lived objects a longer time period to die in the young generation (and hence, to avoid promotion). A consequence of this setting is that minor GC times can increase because of the additional objects to copy. This value and survivor-space sizes may need to be adjusted so as to balance overheads of copying between survivor spaces and tenuring objects that are going to live for a long time. The default settings are:
    SurvivorRatio=1024
MaxTenuringThreshold=0 

    These settings cause all survivors of a scavenge to be promoted. This can place a lot of pressure on the single concurrent thread collecting the tenured generation.

    Note that if it is used with -XX:+UseBiasedLocking, this setting should be 15.

  • -XX:+UseTLAB  This option uses thread-local object allocation.
  • -XX:+UseConcMarkSweepGC  Sets the garbage collector policy to the concurrent (low pause time) garbage collector (also known as CMS).
  • -XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenSweepingEnabled  If you enable CMSClassUnloadingEnabled the GC will sweep PermGen as well, and will remove classes which are no longer used.
  • -XX:NewSize
-XX:MaxNewSize  The young generation is set by a policy that bounds the size from below by NewSize and bounds it from above by MaxNewSize. As the young generation grows from NewSize to MaxNewSize, both eden and the survivor spaces grow.