Garbage collection and heap expansion

Allocation failures

When a JVM runs out of space in the storage heap and is unable to allocate any more objects (an allocation failure), a garbage collection is triggered. The Garbage Collector cleans up objects in the storage heap that are no longer being referenced by applications and frees some of the space. Garbage collection stops all other processes from running in the JVM for the duration of the garbage collection cycle, so time spent on garbage collection is time that is not being used to run applications. For a detailed explanation of the JVM garbage collection process, see Generational Concurrent Garbage Collector.

When a garbage collection is triggered by an allocation failure, but the garbage collection does not free enough space, the Garbage Collector expands the storage heap. During heap expansion, the Garbage Collector takes storage from the maximum amount of storage reserved for the heap (the amount specified by the -Xmx option), and adds it to the active part of the heap (which began as the size specified by the -Xms option). Heap expansion does not increase the amount of storage required for the JVM, because the maximum amount of storage specified by the -Xmx option has already been allocated to the JVM at startup. If the value of the -Xms option provides sufficient storage in the active part of the heap for your applications, the Garbage Collector does not have to carry out heap expansion at all.

At some point during the lifetime of the JVM, the Garbage Collector stops expanding the storage heap, because the heap has reached a state where the Garbage Collector is satisfied with the frequency of garbage collection and the amount of space freed by the process. The Garbage Collector does not aim to eliminate allocation failures, so some garbage collection can still be triggered by allocation failures after the Garbage Collector has stopped expanding the storage heap. Depending on your performance goals, you might consider this frequency of garbage collection to be excessive.

Garbage collection options

You can use different policies for garbage collection that make trade-offs between throughput of the application and the overall system, and the pause times that are caused by garbage collection. Garbage collection is controlled by the -Xgcpolicy option:

-Xgcpolicy:optthruput

This policy delivers high throughput to applications but at the cost of occasional pauses, when garbage collection occurs.

-Xgcpolicy:gencon

This policy helps to minimize the time that is spent in any garbage collection pause. Use this garbage collection policy with JVM servers. You can check which policy is being used by the JVM server by inquiring on the JVMSERVER resource. The JVM server statistics have fields that tell you how many major and minor garbage collection events occur and what processor time is spent on garbage collection.

When you use this policy, it is also worth considering the -Xgc:concurrentScavenge setting - which is not a default setting - if your system has a large heap and is response-time sensitive. In these situations it can help to reduce garbage collection pause times. For more information, see -Xgc:concurrentScavenge.

-XX:+HeapManagementMXBeanCompatibility

This policy is set by default if you are using Java 8 SR5 and above. The policy ensures consistent garbage collection statistics with previous levels of Java. For more information, see -XX:[+|-]HeapManagementMXBeanCompatibility.

-XX:-HeapManagementMXBeanCompatibility

You can choose to opt in to using this policy. The policy enables the default heap changes in Java 8 SR5 and above, however in some cases, the garbage collection statistics might indicate the heap usage to be greater than the maximum heap size. For more information, see -XX:[+|-]HeapManagementMXBeanCompatibility.

You can change the garbage collection policy by updating the JVM profile. For details of all the garbage collection options, see Specifying garbage collection policy in IBM SDK.