Filter
Top Products
4. Database Specific. Use of database can invoke significant path length in i5/OS. Invoking it
efficiently can maximize the performance and value of a Java application.
i5/OS Specific Java Tips and Techniques
y Load the latest CUM package and PTFs
To be sure that you have the best performing code, be sure to load the latest CUM packages and PTFs
for all products that you are using. In particular, performance improvements are often introduced in
new Java Group PTFs (SF99269 for V5R3, SF99291 for V5R4, and SF99562 for V6R1).
y Explore the General Performance Tips and Techniques in Chapter 20
Some of the discussion in that chapter will apply to Java. Pay particular attention to the discussion
"Adjusting Your Performance Tuning for Threads." Specifically, ensure that MAXACT is set high
enough to allow all Java threads to run.
y Consider running Java applications in a separate memory pool
On systems running multiple workloads simultaneously, putting Java applications in their own pool
will ensure that the Java applications have enough memory allocated to them.
y Make sure SMT is enabled on systems that support it
Java applications are always multi-threaded, and should benefit from Simultaneous Multi-threading
(SMT). Ensure that it is turned on by setting the system value QPRCMLTTSK to 1 (On). See
chapter 20 for additional details on SMT.
y Avoid starting new Java VMs frequently
Starting a new VM (e.g. through the JAVA/RUNJVA commands) is expensive on any platform, but
perhaps a bit more so on i5/OS, due to the relatively high cost of starting a new job. Other factors
which make Java startup slow include class loading, bytecode verification, and JIT compilation. As a
result, it is far better to use long-running Java programs rather than frequently starting new VMs. If
you need to invoke Java frequently from non-Java programs, consider passing messages through an
i5/OS Data Queue. The ToolBox Data Queue classes may be used to implement "hot" VM's.
Classic VM-specific Tips
y Use java.compiler=jitc
The JIT compiler now outperforms Direct Execution for nearly all applications. Therefore,
java.compiler=jitc should be used for most Java applications. One possible exception is when startup
time is a critical issue, but JIT may be appropriate even in these cases. Setting
java.compiler is
not necessary for Classic on V6R1, or for IBM Technology for Java on either V5R4 or V6R1 -- the
JIT compiler is always used in these cases.
y Delete existing DE program objects
When using the JIT, JVAPGM objects containing Direct Execution machine code are not used.
These program objects can be large, so removing the unused JVAPGM objects can free up disk space.
This is not needed on V6R1. To determine if your class/zip/jar file has a permanent, hidden program
object on previous releases, use the DSPJVAPGM command. If a Java program is associated with the
file, and the “Optimization” level is something other than *INTERPRET, use DLTJVAPGM to delete
the hidden program. DLTJVAPGM does not affect the jar or zip file itself; only the hidden program.
Do not use DLTJVAPGM on IBM-shipped JDK jar files (such as rt.jar). As explained earlier, the JIT
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
© Copyright IBM Corp. 2008 Chapter 7 - Java Performance 136