Garbage Collector Overview

Java 7 implements a new Garbage collector called the G1. The collector splits the heap up into fixed-size regions and tracks the live data in those regions. It keeps a set of pointers — the "remembered set" — into and out of the region. When a GC is deemed necessary, it collects the regions with less live data first (hence, "garbage first"). Often, this can mean collecting an entire region in one step: if the number of pointers into a region is zero, then it doesn't need to do a mark or sweep of that region. see g1

  • JVM 1.4.2 has 4 garbage collectors :
    • The Serial Collector (default ) : is a stop-the-world collector and is meant to be used by small applications. It runs on a single thread.
    • The Throughput Collector : . is set by -XX:+UseParallelGC and the number of gc threads is set by -XX:ParallelGCThreads=<desired number>, this gc is to be used by large applications, the throughput collector is a generational collector similar to the serial collector but with multiple threads. On a host with 1 CPU the throughput collector will likely not perform as well as the serial collector because of the additional overhead for the parallel execution (e.g., synchronization costs). On a host with 2 CPUs the throughput collector generally performs as well as the serial garbage collector and a reduction in the minor garbage collector pause times can be expected on hosts with more than 2 CPUs. The throughput collector will throw an out-of-memory exception if around 98% of time is spend doing garbage collection.
    • The Concurrent Low Pause Collector: is set by -XX:+UseConcMarkSweepGC, it trades processor resources for shorter major collection pause times. The concurrent collector uses a single garbage collector thread that runs simultaneously with the application threads with the goal of completing the collection of the tenured generation before it becomes full. In normal operation, the concurrent collector is able to do most of its work with the application threads still running, so only brief pauses are seen by the application threads. As a fall back, if the concurrent collector is unable to finish before the tenured generation fills up, the application is paused and the collection is completed with all the application threads stopped. Such collections with the application stopped are referred to as full collections and are a sign that some adjustments need to be made to the concurrent collection parameters.
    • The Incremental Low Pause Collector: this collector is used only if -XX:+UseTrainGC is passed on the command line. This collector has not changed since the J2SE Platform version 1.4.2 and is currently not under active development. It will not be supported in future releases.
  • In Java 5.0 the choice of the collector is based on the class of the machine on which the application is started.
  • JVMs upto and including version 1.3.1 do not have parallel garbage collection.
  • Active young objects are copied between survivor spaces, until they are old enough to be tenured.
  • The ratio between the space reserved for the young space and the old is set by -XX:NewRatio=2,
  • -XX:SurvivorRatio sets the ratio between each survivor space and eden, for example -XX:SurvivorRatio=6 to be 1:6. In other words, each survivor space will be one eighth of the young generation (not one seventh, because there are two survivor spaces).
  • You should avoid using object pools as these fool the garbage collector into thinking objects are live when they really aren't. This may have worked before exact garbage collection became popular, but this is just not a good idea for any modern Java Virtual Machines.
  • The command line argument -verbose:gc prints information at every collection.
  • Tuning Tips : Unless you have problems with pauses, try granting as much memory as possible to the virtual machine. The default size (64MB) is often too small. Setting -Xms and -Xmx to the same value increases predictability by removing the most important sizing decision from the virtual machine. On the other hand, the virtual machine can't compensate if you make a poor choice. Be sure to increase the memory as you increase the number of processors, since allocation can be parallelized.
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License