Is Java's "heap" functionality killing your application's performance?

By David Mayle

When I started working with Java on the iSeries, my first impressions were not very favorable because the performance was horrible. Over the years, however, I've found that by using a few simple tricks, Java's performance can be greatly improved.

One of the biggest performance killers in an otherwise well-written application is a process known as "garbage collection." When objects are created in Java, they are placed on what is called a "heap," and periodically the garbage collector removes objects that are no longer needed. By default, when the Java Virtual Machine (JVM) starts, the iSeries sets the initial heap size to an arbitrary value based on what JVM you are using, what your OS level is, etc. If the application is performing poorly, however, this value may need to be adjusted. The reason is that if the value of the initial heap size is set too small, the JVM may be spending most of its effort continually performing garbage collection. Conversely, if the value is set too high, the application may run fine but take a large hit when the garbage collector finally does run because it now has to clean up a huge amount of objects. Unfortunately, there is no easy way to tell what the optimum value should be before running a Java program. It's more a matter of trial and error and experimenting with different values to find the one that is optimum.

The easiest way to see what effect the garbage collection process is having on your Java application is to start it with verbose garbage collection enabled. To do this, you can simply use the -verbosegc option when you call the Java program.

java -verbosegc myJavaProgram

When verbose garbage collection is enabled, the JVM will write the results of each garbage collection to standard output. This will generate a spooled file on your iSeries (unless you have redirected standard output somewhere else) that can be reviewed. The spooled file looks like this:

GC: initial heap(KB) 32768; maximum heap(KB) 240000000; virtual machine identifier F11EBE6844002000;  heap identifier F11EBE684400

GC 1: starting collection, invoked.                                                                                              

GC 1: 01/16/2008 14:11:33                                                                                                         

GC 1: live objects 7514; collected objects 29930; collected(KB) 6160.                                                            

GC 1: queued for finalization 0; total soft references 73; cleared soft references 0.                                            

GC 1: current heap(KB) 15904; current threshold(KB) 32768.                                                                       

GC 1: collect (milliseconds) 104.                                                                                                 

GC 1: current cycle allocation(KB) 493; previous cycle allocation(KB) 15612.                                                     

GC 1: total weak references 64; cleared weak references 0.                                                                        

GC 1: total final references 84; cleared final references 15.                                                                    

GC 1: total phantom references 0; cleared phantom references 0.                                                                   

GC 1: total JNI global weak references 0; cleared JNI global weak references 0.                                                               GC 1: collection ending 01/16/08 14:11:33

The key values to look at are the number of milliseconds spent on garbage collection, the current heap size, and the time interval between the collections. If garbage collection is being performed every few seconds, you should consider increasing the initial heap size to improve performance. Conversely, if garbage collection is only occurring every few hours but consuming a large number of milliseconds when it does happen, you probably need to decrease the initial size of the heap.

The current heap size value is useful for determining where to set your initial heap size. This number will fluctuate as your application runs, but a good rule of thumb is that you never want your initial heap size to be smaller than this value. The current heap size can also be used to detect memory leaks. If the current heap size continues to grow, something is creating objects for which the JVM cannot reclaim memory via the garbage collection process.

Adjusting the initial heap size can only be done when the JVM is started. Once started, the size of the heap cannot be changed. Changing the initial heap size is accomplished with the Java -Xms option.

java -Xms64m myJavaProgram

The values for the heap size must be set as exponential values of the base 2, so valid values are 2, 4, 8, 16, 32, etc. The example above tells the JVM to set the initial heap size to 64 megabytes. By adjusting this value and reviewing the verbose garbage collection output you might very well be able to significantly improve the performance of your Java application.

Dave Mayle is a senior developer for Eaton Corporation, a global leader in electrical systems and components for power quality, distribution, and control. Dave has worked on the iSeries/System i since 1993 and is currently focused on developing Java, Web, and ILE applications. Dave has written numerous technical articles on the iSeries and is a three-time Speaker of Merit award winner at COMMON. Dave is a graduate of Bucknell University and can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..