Java Performance Tuning
Contents
New JVM (J9 based)
This JVM is an adaption of the AIX JVM to the IBM i. For most purposes it behaves identically to the AIX JVM and runs in the PASE subsystem.
Classic JVM
The Classic JVM compiles to MI-code, and has a different garbage collection scheme than most other JVM's. If performance matters, it is frequently chosen to put Java programs in a separate storage pool (reserved memory) to avoid being swapped to disk.
Problem: Application makes long pauses randomly
That the application makes long pauses randomly is usually caused by the garbage collection thread running in the background not being able to keep up. If a new garbage collection is found to be needed while the previous garbage collection is still running, the application is completely paused until the garbage collection has finished.
Slow garbage collection is typically caused by the memory occupied by the JVM being swapped out to disk as OS/400 needs the memory for other purposes. This frequently happens in busy sub-systems where a lot of programs are being run. If OS/400 cannot read in the memory contents quickly enough the garbage collector gets too slow, and the application is being paused randomly.
A simple remedy for this is to run the performance critical programs in their own subsystem with their own storage pool (reserved memory). The size of the storage pool can only be found by trial-and-error by experimenting with various garbage collection settings and seeing the typical size of the Java heap after garbage collection has finished.
In order to get information about the garbage collector, you should run your Java program with the *VERBOSEGC option, which prints out statistics about each run to QPRINT.
