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.
