In the Java generational memory management model, the young generation creates new objects and the garbage collector gathers them when they are no longer used. For example, if the young generation creates a new object, and a reference is maintained, then the garbage collector moves that object to the old generation.

Tip:

If you intend to use the garbage first (G1) collector, let the Java virtual machine (JVM) handle this aspect of the heap because specific settings can affect the performance of the G1 collector adversely.

For more information on fine-tuning memory and garbage collection settings and instructions, see Fine-tuning JVM options.

The processing model of PingFederate is mostly geared towards short-lived transactions, such as single sign-on and token processing and not long-held, interactive, user sessions. Because most of the objects created are relatively short-lived, it does not make sense to promote short-lived objects to the old generation because they are not needed for long. When the young generation fills up, space must be made for new objects. To allow for more space, objects still in use in the young generation must be moved to the old generation. Moreover, those objects will become garbage and need to be collected from the old generation.

The old generation is typically more expensive to clean up than the young generation. The old generation is cleaned only during a full garbage collection, which happens when the JVM has almost reached the value of the maximum heap variable -Xmx and the entire heap must be cleaned. With multiple threads by default on systems with multiple cores, the young generation is garbage collected more often and so the pauses for collections are shorter.

By default, the JVM tends to size the generations biased to the old generation, giving it most of the space of the heap. This results in moving objects more frequently from the young generation into the old generation to make space for new objects, and more frequent full collections as the old generation fills up. By configuring the JVM to provide more memory to the young generation, it reduces the frequency of full, more costly, collections. You can either specify fixed values for the size of the young generation or modify the ratio of young generation to old generation.

To specify a fixed value for the young generation, use the -XX:NewSize= and -XX:MaxNewSize= arguments. These arguments are to the young generation what the minimum heap variable (-Xms) and the maximum heap variable (-Xmx) are to the entire heap. The -XX:NewSize= and -XX:MaxNewSize= arguments define the initial or minimum and the maximum sizes of the young generation. The same reasoning that applies to the minimum and maximum heap variables also applies when adjusting these values.

To specify a ratio between the old and new generation size, use the -XX:NewRatio= argument. For example, setting -XX:NewRatio=3 means that the ratio between the young and old generation is 1:3. The size of the young generation is 25% of the total heap size.

In a mostly short-lived object environment, give 50 - 60% of the heap to the young generation. See the following table for examples.
Setting the JVM options according to young generation sizing
Young generation bias condition JVM options
To fix a heap size of 2 GB with 50% the young generation bias using the NewSize argument 
-Xms2048m
-Xmx-2048m
-XX:NewSize=1024m
-XX:MaxNewSize=1024m
To fix a heap size of 2 GB with 50% the young generation bias using the NewRatio argument 
-Xms2048m
-Xmx-2048m
-XX:NewRatio=1