Basic GC Tuning

Sizing the Heap

• -XmsN
• -XmxN

Summary

• The JVM will attempt to find a reasonable minimum and maximum 
  heap size based on the machine it is running on.
• Unless the application needs a larger heap than the default, consider 
  tuning the performance goals of a GC algorithm (given in 
  the next chapter) rather than fine-tuning the heap size.

Sizing the Generations

• -XX:NewRatio=N
  • Set the ratio of the young generation to the old generation.
  • default value of 2.
  • Initial Young Gen Size = Initial Heap Size / (1 + NewRatio) 
    • By default, then, the young generation starts out 
      at 33% of the initial heap size.
• -XX:NewSize=N 
  • Set the initial size of the young generation.
  • If that option NewSize flag is set, it will take precedence over the value calculated fromthe NewRatio.
• -XX:MaxNewSize=N 
  • Set the maximum size of the young generation.
  • By default, that maximum is also set using the 
    NewRatio value, though it is based on the maximum (rather than initial) heap size.
• -XmnN 
  • Shorthand for setting both NewSize and MaxNewSize to the same value.
  • When a heap size is fixed (by setting -Xms equal to -Xmx),it is usually preferable to use -Xmn to specify a fixed size for the young generation as well.

Summary

• Within the overall heap size, the sizes of the generations are 
  controlled by how much space is allocated to the young generation.
• The young generation will grow in tandem with the overall heap 
  size, but it can also fluctuate as a percentage of the total heap 
  (based on the initial and maximum size of the young generation).

Sizing Permgen and Metaspace

• When the JVM loads classes, it must keep track of certain metadata about those classes. 
  From the perspective of an end user, this is all just bookkeeping information. This data 
  is held in a separate heap space. In Java 7, this is called the permgen (or permanent 
  generation), and in Java 8, this is called the metaspace.
• Permgen and metaspace are not exactly the same thing. In Java 7, permgen contains 
  some miscellaneous objects that are unrelated to class data; these are moved into the 
  regular heap in Java 8. As end users, all we need to know is that permgen/metaspace holds a bunch of class-related data, and that there are certain circumstances where the size of that region needs to be tuned.
• Note that permgen/metaspace does not hold the actual instance of the class (the Class 
  objects), nor reflection objects (e.g., Method objects); those are held in the regular heap. 
  Information in permgen/metaspace is really only used by the compiler and JVM runtime, 
  and the data it holds is referred to as class metadata.
• the metaspace rarely needs to be sized—because (unlike permgen) metaspace will by default use as much space as it needs.
• These memory regions behave just like a separate instance of the regular heap. They are 
  sized dynamically based on an initial size and will increase as needed to a maximum size.
• permgen, 
  • -XX:PermSize=N and -XX:MaxPermSize=N.
• Metaspace 
  • -XX:MetaspaceSize=N and -XX:MaxMetaspaceSize=N.
• Default maximum metaspace size Unlimited 
  • Because the default size of metaspace is unlimited, there is the possibility (particularly in a 32-bit JVM) that a Java 8 application can run out of memory by filling up metaspace.
• Heap dumps can be used to diagnose what classloaders exist, which in 
  turn can help determine if a classloader leak is filling up permgen (or metaspace). 
  Otherwise, jmap can be used with the argument -permstat (in Java 7) or -clstats (in 
  Java 8) to print out information about the classloaders.

Summary

• The permanent generation or metaspace holds class metadata (not class data itself). It behaves like a separate heap.
• For typical applications that do not load classes after startup, the initial size of this region can be based on its usage after all classes have been loaded. That will slightly speed up startup.
• Application servers doing development (or any environment where classes are frequently redefined) will see an occasional full GC caused when permgen/metaspace fills up and old class metadata is discarded.

Controlling Parallelism

• All GC algorithms except the serial collector use multiple threads. The number of these 
  threads is controlled by the -XX:ParallelGCThreads=N flag. The value of this flag affects 
  the number of threads used for the following operations:
  • Collection of the young generation when using -XX:+UseParallelGC
  • Collection of the old generation when using -XX:+UseParallelOldGC
  • Collection of the young generation when using -XX:+UseParNewGC
  • Collection of the young generation when using -XX:+UseG1GC
  • Stop-the-world phases of CMS (though not full GCs)
  • Stop-the-world phases of G1 (though not full GCs)
• Because these GC operations stop the application threads from executing, the JVM 
  attempts to use as many CPU resources as it can in order to minimize the pause time. 
  By default, that means the JVM will run one thread for each CPU on a machine, up to 
  eight. Once that threshold has been reached, the JVM only adds a new thread for every 
  five-eighths of a CPU. So the total number of threads (where N is the number of CPUs) 
  on a machine with more than eight CPUs is: 
  • ParallelGCThreads = 8 + ((N - 8) * 5 / 8)
• Note that this flag does not set the number of background threads used by CMS or G1

Summary

• The basic number of threads used by all GC algorithms is based 
  on the number of CPUs on a machine.
• When multiple JVMs are run on a single machine, that number 
  will be too high and must be reduced.

Adaptive Sizing

• The sizes of the heap, the generations, and the survivor spaces can vary during execution 
  as the JVM attempts to find the optimal performance according to its policies and 
  tunings.
• This is a best-effort solution, and it relies on past performance: the assumption is that 
  future GC cycles will look similar to the GC cycles in the recent past. That turns out to 
  be a reasonable assumption for many workloads, and even if the allocation rate suddenly 
  changes, the JVM will readapt its sizes based on the new information.
• At a global level, adaptive sizing is disabled by turning off the -XX:-UseAdaptiveSize 
  Policy flag (which is true by default). With the exception of the survivor spaces (which 
  are examined in detail in the next chapter), adaptive sizing is also effectively turned off 
  if the minimum and maximum heap sizes are set to the same value, and the initial and 
  maximum sizes of the new generation are set to the same value.

Summary

• Adaptive sizing controls how the JVM alters the ratio of young 
  generation to old generation within the heap.
• Adaptive sizing should generally be kept enabled, since adjusting 
  those generation sizes is how GC algorithms attempt to meet 
  their pause time goals.
• For finely tuned heaps, adaptive sizing can be disabled for a small 
  performance boost.