This subsection explains the mechanism of garbage collection.
Garbage Collection is a technology that automatically collects the memory area that is no longer required by a program and makes the memory area available for use by other programs.
The processing of the program stops in the middle of garbage collection execution. Consequently, whether the garbage collection can be run appropriately or not, tremendously impacts the system performance.
The Java objects created in the program using new, occupy the memory space that is managed by JavaVM. The time period from the point where Java object gets created up to the point where it becomes redundant is called the lifespan of a Java object.
There are two types of Java objects; those with a short lifespan and those with a long lifespan. In the case of a Java application running on the server, a number of Java objects are created by request and response, or by transaction management. These Java objects have a short lifespan, as they become redundant when the processing ends. On the other hand, the Java objects that are continuously being used while the application is running have a long lifespan.
For effectively executing garbage collection, you need to make the memory collection effective by executing garbage collection for the objects with short life spans. Avoiding unnecessary execution of garbage collection for repeatedly used objects with long lifespans helps to prevent the deterioration of system performance. This is implemented by generation-wise garbage collection.
In generation-wise garbage collection, the Java objects are managed by separating them into two areas; the New area that stores objects with a short lifespan, and the Tenured area that stores objects with a long lifespan. The New area is further divided into the Eden area that holds objects that have been recently created using new, and the Survivor area that holds objects that have not been collected even after garbage collection has run multiple times. The Java objects of the New area for which garbage collection is executed more than a fixed number of times are considered as the Java objects that are required for a long period, and those Java objects move to the Tenured area.
The following figure shows an overview of the memory space and the Java objects managed by the generation-wise garbage collection:
Figure 7-1 Overview of the memory space and the Java objects managed by generation-wise garbage collection
The garbage collection executed by the generation-wise garbage collection is of the following two types:
Generally, a copy garbage collection can be processed in a shorter time period as compared to a full garbage collection.
The garbage collection processing is described as follows with an example of a certain Java object (object A):
If objects are moved as mentioned above, then the used size of the Tenured area increases. However, a full garbage collection occurs when the Tenured area is used up to a constant size.
While tuning JavaVM, the appropriate settings of the size and ratio of the respective memory spaces in JavaVM will help to prevent the movement of unnecessary objects to the Tenured area, and thereby prevent the frequent occurrence of a full garbage collection.
The number of times copy garbage collection is executed for an object is called the age of the object.
The following figure shows the relation between the lifespan and the age of an object:
Figure 7-2 Relation between the lifespan and the age of an object
After the application has started, the initialization process has finished, and the copy garbage collection has been executed a number of times, the objects with a long lifespan that are required for a long period, move to the Tenured area. As a result, shortly after starting the application, the Java heap reaches a stable state and most of the Java objects that get created are the objects that have a short lifespan. Especially, if the tuning of the New area has been performed appropriately, then after the Java heap stabilizes, a majority of the objects that are objects with a short lifespan get collected during the first copy garbage collection.
In JavaVM, the memory space of the New area for which copy garbage collection is executed, is divided into the Eden area and the Survivor area. The Survivor area is furthermore divided into the From space and the To space. The From space and the To space have the same memory size.
The following figure shows the configuration of the New area:
Figure 7-3 Configuration of the New area
An Eden area is the area where the objects created using new are stored initially. When new is executed in a program, memory from the Eden area is allocated.
When the Eden area becomes full, copy garbage collection is executed. The following processing is performed in copy garbage collection:
As a result, the Eden area and the To space become empty, and the objects that are in use remain in the From space.
The following figure shows the movement of objects when copy garbage collection is executed:
Figure 7-4 Movement of objects that occurs during copy garbage collection
In this way, when copy garbage collection occurs, the objects that are in use move to and fro between the From space and the To space. If the objects with a long lifespan continue to move to and fro, however, copy processing becomes an overhead. To prevent this, set a threshold value for the frequency of switching the Java objects between the From space and the To space, so that the Java objects whose age has reached the threshold value move to the Tenured area.
The activity of moving those Java objects whose age has not reached the threshold value to the Tenured area, is called Saving. Saving occurs when the number of in-use objects in the Eden area and the From space increase and the memory size of the To space, where these objects will be moved to, is not sufficient to hold those objects during copy garbage collection. In such a case, the objects that could not move to the To space move to the Tenured area.
Figure 7-5 Saving objects
When the objects are saved, the objects with a short lifespan that originally were not supposed to be saved in the Tenured area, get saved in the Tenured area. If this repeats, the objects that were supposed to be collected by copy garbage collection keep getting accumulated in the memory space, thereby increasing the memory usage of Java heap, and finally a full garbage collection occurs.
The following figure shows the change in memory usage when the objects are saved:
Figure 7-6 Change in memory usage when the objects are saved
In full garbage collection, a system might stop from a few seconds to 10 seconds.
As a result, when determining the configuration of the memory space and memory size, you must achieve a balance between the Eden area and the Survivor area, so that the objects are not saved.
With JavaVM, you can use the area called the Explicit heap, in addition to the Eden area, Survivor area, and Tenured area. A garbage collection is not executed in the Explicit heap area.
Specify objects to be saved in the Explicit heap area using the automatic allocation setup file and the Explicit Memory Management functionality API. At the timing of the specified objects being moved from the Survivor area to the Tenured area, the specified objects are moved to the Explicit heap area. You can specify the objects with a long lifespan that are not recovered by copy garbage collection, to reduce the memory usage of the Tenured area and to prevent the occurrence of a full garbage collection. You can also create the specified objects in the Explicit heap area using the automatic allocation setup file of the Explicit Memory Management functionality or the Explicit Memory Management functionality API.
For details about the Explicit Memory Management functionality, see 8. Preventing the occurrence of full garbage collection using the Explicit Memory Management functionality in the uCosminexus Application Server Expansion Guide.