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 tail 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.
5.4.4 Static compilation
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.
Chapter 5. Performance tuning 127
