libraries and environments may require a particular version. The Classic VM continues to support
JDK 1.3, 1.4, 1.5 (5.0), and 1.6 (6.0) in V5R4, and JDK 1.4, 1.5 (5.0), and 1.6 (6.0) in V6R1.
3. The Classic VM supported an i5/OS-specific feature called Adopted Authority. IBM Technology for
Java does not support this feature, so applications which require Adopted Authority must run in the
Classic VM. This will not affect most applications. Applications which do use Adopted Authority
should consider migrating to APIs in IBM Toolbox for Java which can serve a similar purpose.
4. Java applications can call native methods through the Java Native Interface (JNI) with either VM.
When using IBM Technology for Java, these native programs must be compiled with teraspace
storage enabled. In addition, whenever a buffer is passed to JNI functions such as
GetxxxArrayRegion
, the pointer must point to teraspace storage.
5. When using 32-bit IBM Technology for Java runs in a 32-bit PASE environment, any PASE native
methods must also be 32-bit. With 64-bit IBM Technology for Java, PASE native methods must be
64-bit. The Classic VM can call both 32-bit and 64-bit PASE native methods. All of the VMs can
call ILE native methods as well.
Performance Considerations
1. When properly tuned, applications will tend to use significantly less memory when running in IBM
Technology for Java than in the Classic VM. Performance tests have shown a reduction of 40% or
more in the Java heap for most applications when using the 32-bit IBM Technology for Java VM,
primarily because object references are stored with only 4 bytes (32 bits) rather than 8 bytes (64 bits).
Therefore, an application using 512 MB of heap space in the 64-bit Classic VM might require 300
MB or even less when running in 32-bit IBM Technology for Java. The difference between the
Classic VM and 64-bit IBM Technology for Java is somewhat less noticable, but 64-bit IBM
Technology for Java will still tend to have a smaller footprint than Classic for most applications.
2. The downside to using a 32-bit address space is that it limits the amount of memory available to the
application. As discussed above, the 32-bit VM has a maximum heap size of 3328 MB, although
most applications will have a practical limit of 3 GB or less. Applications which require a larger heap
should use 64-bit IBM Technology for Java or the Classic VM. Since applications will use less
memory when running in the 32-bit VM, this means that applications which require up to about 5 GB
in the Classic VM will probably be able to run in the 32-bit VM. Of course, applications with heap
requirements near the 3 GB limit will require extra testing to ensure that they are able to run properly
under full load over an extended period of time.
3. Applications which use a single VM to fully utilize large systems (especially 8-way and above) will
tend to require larger heap sizes, and therefore may not be able to use the 32-bit VM. In some cases it
may be possible to divide the work across two or more VMs. Otherwise, it may be necessary to use
one of the 64-bit VMs on large systems to allow larger heap sizes.
4. Because calls to native ILE code are more expensive in IBM Technology for Java, extra care should
be taken when moving Java applications which make heavy use of native ILE code to the new VM.
Performance testing should be performed to determine whether or not the overhead of the native ILE
calls are hurting performance in your application. If this is an issue, the techniques discussed above
should be used to attempt to improve the performance. If the performance is still unacceptable, it
may be best to continue using the Classic VM at this time. Conversely, applications which make use
of i5/OS PASE native methods may see a performance improvement when running in IBM
Technology for Java due to the reduced overhead of calling i5/OS PASE methods.
5. Remember that microbenchmarks (small tests to exercise a specific function) do not provide a good
measure of performance. Comparisons between the IBM Technology for Java and Classic based on
microbenchmarks will not give an accurate picture of how your application will perform in the two
VMs, because your application will have different characteristics than the microbenchmark. The best
way to determine which VM provides the best performance for your application is to test with the
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 7 - Java Performance
133
