Support MC Press - Visit Our Sponsors

 

 

Forums Sponsor

Popular Forums

How to display many subfile columns (456 views) Picking the Right Partner for RPG (291 views) Printing Bar Codes in an internal output spec's (141 views) DB2 Web query vs SEQUEL (65 views) ANSI to UTF-8 on IFS (48 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (47 views) Schedule Announced for Conference & Workshops on SOA, SaaS, Virtualisation & ECM (31 views)

Forums

   

 

Search Sponsor

  

Popular Searches

POPULAR SEARCHES 1. DB2 web query 2. display PDF 3. seiden 4. pdf 5. web services 6. subfiles 7. subfile 8. spooled files and pdf 9. Chris Smith 10. green

Search

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.