Garbage Collection in SUN JDK

The Java Virtual Machine (JVM) allows you to write programs once and run them anywhere. Usually, JVMs are optimized for an operating system in combination with the underlying hardware platform.

The leading JVM vendors are Sun HotSpot JVM and Oracle JRockit for Windows, Unix, and Linux platform. Please note that Oracle is the vendor for both JRockit and Sun HotSpot JVMs. The Sun HotSpot JVM is widely used and is the default choice for Oracle SOA Suite implementations. Therefore, we will discuss the Oracle Sun HotSpot JVM performance tuning in detail.

Garbage collection process

Garbage collection (GC) is a process of JVM that removes the unused Java objects from the JVM heap to recycle the JVM resources. The configuration of the underlying JVM for the WebLogic servers affects the Oracle BPEL Process Manager performance. The details will be discussed in the following sections.

The Java heap memory space is divided into three sections: young, tenured, and permanent generation, as shown in the following diagram. Minor garbage collection occurs at the young generation space and major garbage collection occurs at the tenured space.

Young generation

Young generation memory space is used whenever we create objects in Java. That is why the young generation memory space is also known as new space. The Java objects enter the young generation space and they either get the garbage collected or move into the tenured generation space. Usually the young generation memory space is smaller than the tenured generation space, therefore it has shorter collection times as compared to the full GC in tenured space. The garbage collection process in the young generation is known as Minor Garbage Collection (minorGC).

Tenured generation

The Java objects in the tenured generation space last longer than the young generation space. Usually, the tenured generation memory space is bigger than the young generation space and it takes more time as compared to minor garbage collection occurring in the young generation. The garbage collection process in the tenured generation is known as Major Garbage Collection (majorGC).

Permanent generation

Permanent generation holds the data needed by VM to describe objects (describing classes and methods). It is recommended that we always allocate enough permanent generation space to load Oracle SOA Suite library classes in a JVM. The default permanent generation size is not sufficient for Oracle SOA Suite. There is no garbage collection process in permanent generation space for a JVM.

Garbage collection tuning

The main objective of garbage collection tuning is to achieve less frequent garbage collection with less pause time. Tuning the garbage collection process for a JVM is very important because an application that spends about 10 percent of its time in garbage collection can lose about 75 percent of its throughput when scaled out to multiple processors.

In this section, we will learn the options to tune JVM to run the SOA Suite optimally. The best way to tune the JVM and eliminate memory-related errors is to adjust JVM memory parameters. The JVM parameters are usually part of the WebLogic server start-up scripts. The default install values are not sufficient and may not provide an optimal runtime performance for an Oracle SOA Suite implementation. You need to ensure that the default JVM parameters are updated. The recommended heap size for Oracle SOA Suite is 4 GB. Some of the major JVM parameters for JDK 6 are as follows:

-Xms4096m \ - Minimum Heap
-Xmx4096m \ - Maximum Heap
-Xss512k \ - Set maximum native stack size for any thread
-XX:+UseConcMarkSweepGC
-XX:GCTimeRatio=99 \ - The ratio of GC time to application time
-XX:MaxGCPauseMillis=20 \ - Pause times of 20ms desired.
-XX:PermSize=512m \ - Permanent Size
-XX:MaxPermSize=512m \
-XX:NewSize=1024m \ - Minor GC (Young Generation)
-XX:MaxNewSize=1024m \
-XX:SurvivorRatio=6 \

During performance tuning, it is important to ensure that all endpoint applications are responding properly. When you adjust the minimum and maximum heap parameters, please ensure that you adjust the other parameters as well. The PermSize parameter can be constant but the NewSize andMaxNewSize parameters require tuning.

It is recommended for better performance that we keep the same values for following pairs for JVM parameters:

·         Minimum heap size (-Xms) and maximum heap size (-Xmx)

·         -XX:PermSize and -XX:MaxPermSize

·         -XX:NewSize and -XX:MaxNewSize

Choosing the garbage collection algorithm

One of the key JVM parameters is the choice of the garbage collectors. Two of the major garbage collectors are listed as follows for reference:

·         Mark and sweep (-XX:+UseConcMarkSweepGC)

Mark and sweep garbage collection algorithm minimizes the garbage collection pause time that enables us to avoid impacting the production transaction during the GC process. This algorithm will run the tenured generation concurrently with the execution of the application.

·         Throughput collector parallel collector (XX:+UseParallelGC)

That throughput collector distributes the garbage collection load across CPUs; therefore maximizing throughput.

It is ideal for using with multiprocessor machines usually with four or more processors.

Select NewSize

Set -XX:NewSize to be one-fourth of the size of the maximum heap size. The larger the young generation space means smaller the tenured space. One can't specify the tenured generation size directly; the size of the tenured generation space is determined by the total heap size and NewSize.

Tenured generation space size = Total heap size – NewSize

The higher values of NewSize will result in a lesser minor garbage collection.

To verify the JVM performance, use Oracle SOA Suite Enterprise Manager Console. Select the WebLogic domain and use the JVM performance to view the performance details.

The other available options are to use the WebLogic Console or JVisualVM.

Select heap size

Set the values of -Xms and -Xmx to around 80 percent of the available physical memory on a server. The remaining 20 percent memory is left for the operating system and other processes. Setting the value of -Xmx to a very high value will result in a slower majorGC that occurs less frequently. Setting too high values for a JVM heap size can cause wasted memory and performance impact during a majorGC. Please note that on a 32-bit OS server(s) a JVM can only use a maximum 2.5 GB.

Garbage collection tool – JVisualVM

JVisualVM is a GUI-based JVM monitoring, troubleshooting, and profiling tool that can be used to diagnose JVM performance, JVM garbage collection processes to tune JVM parameters for an application platform such as Oracle SOA Suite. The JVisualVM tool is part of JDK Version 6 that combines several JVM utilities such as JConsole, jstat, jinfo, jstack, and jmap under one roof.

To start the JVisualVM, go to the bin directory of the JDK install and invoke the jvisualvm application. The Java Visual VM tool provides a view of all the Java parameters set for a WebLogic server environment, as shown in the following screenshot:

Using the JVisualVM tool one can see the live CPU usage, GC activity, and Heap activity for an application such as Oracle SOA Suite, as shown in the following screenshot:

You can also view the JVM performance details for the garbage collection activity by adding the following parameters as part of the WebLogic start-up scripts:

·         –XX:+PrintGC: Outputs the basic information at every garbage collection

·         –XX:+PrintGCDetails: Provides the size of live objects before and after garbage collection for the various generations, the total available space for each generation, and the length of time the collection took

·         –XX:+PrintGCTimeStamps: Provides a timestamp at the start of each collection that helps us correlate garbage collection logs with other logged events

·         –XX:+PrintGCTimeStamps: Provides a timestamp at the start of each collection that helps us correlate garbage collection logs with other logged events

You are recommended to create a table with JVM parameters and its impact on the performance during the tuning process, as shown in the following table using excel or word. In the tuning process always analyze GC activities for pause time, frequency, and average memory footprint.