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.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online