IBM SG24-6526-00 User Manual

Chapter 5. Performance tuning 

A simple way to view this file is to map a PC drive to the iSeries integrated file system (IFS) 
and then use a PC editor. Another simple way to view this file is to use the OS/400 Edit File 
(EDTF) command. An another less friendly but useful technique is to use the Qshell

command. You can learn more about each of these techniques in Chapter 6, “Tips and 
techniques” on page 137. 

The following example shows sample output produced by verbose garbage collection. 

GC: initial heap(KB) 262144; maximum heap(KB) 0; virtual machine identifier 
F246AFEE6B000048;  heap identifier F246AFEE6B000048.…
GC 1: starting collection, threshold allocation reached.…
GC 1: live objects 149160; collected objects 1810659; collected(KB) 240977.…
GC 1: queued for finalization 0; total soft references 77; cleared soft references 49.…
GC 1: current heap(KB) 311328; current threshold(KB) 262144.…
GC 1: collect (milliseconds) 2106.…
GC 1: current cycle allocation(KB) 17133; previous cycle allocation(KB) 262172.…
GC 1: total weak references 6; cleared weak references 1.…
GC 1: total final references 516; cleared final references 47.…
GC 1: total phantom references 0; cleared phantom references 0.…
GC 1: total old soft references 0; cleared old soft references 0.…
GC 1: total JNI global weak references 0; cleared JNI global weak references 0.…

The first line is output once. It confirms the application settings. At the time this output was 
run, the Xms setting was 256m, which is 262144 bytes. Xmx was not specified as indicated by 
the maximum size of 0. 

The lines that follow have a number after the GC. This is the cycle number, so all these lines 
relate to the first garbage collection. Later a set of lines beginning with 

GC 2

 appear and so on. 

The value 240977 at the end of the second GC 1 line indicates how much heap was 
recovered by the collection. The value 311328 on the fourth line indicates the size of the heap 
after the collection. The other value on this line 262712 is the threshold, which specifies how 
much the heap needs to grow before the next collection. This is based on the Xms parameter. 
If the application was running for some time and this is a typical workload, then these figures 
give a good indication of the ideal heap size. It varies between the size after collection 
(311328 in this example) and this size, plus the threshold (311328 + 262144). 

If you increase Xms, the threshold increases, so the collections occur less often. In general, 
this improves performance. However if you increase it too much, then the collection has a 
greater impact on performance when they do occur. Also if you let the heap grow too large, 
then you may exceed real memory in the pool and cause faulting. On the other hand, if you 
have insufficient real memory, you may improve performance by reducing Xms and keeping 
the heap smaller to reduce faulting. 

OS/400 offers the ability to statically compile Java classes and JAR files. This is done using 
the Create Java Program (CRTJVAPGM) command. A service program (similar to a familiar 
iSeries program but with multiple entry points) is created. Unlike traditional languages (for 
example, RPG or Cobol), this program does not appear in any library. Instead, it is attached to 
the Java class or JAR file. The iSeries class loader detects the presence of this service 
program and uses it if it is present. This saves the overhead of Just In Time (JIT) compilation 
and the level of optimization may be greater. This step used to be extremely valuable in the 
early releases of Java on the iSeries, but it is less important now since the JIT compiler has 
improved greatly.