later releases the cache is enabled and the maxpgms set to 20000 by default, so no adjustment is usually
necessary.
The verification cache operates by caching JVAPGMs that have been dynamically created for
dynamically loaded classes. When the verification cache is not operating, these JVAPGMs are created as
temporary objects, and are deleted as the JVM shuts down. When the verification cache is enabled,
however, these JVAPGMs are created as persistent objects, and are cached in the (user specified)
machine-wide cache file. If the same (byte-for-byte identical) class is dynamically loaded a second time
(even after the machine is re-IPLed), the cached JVAPGM for that class is located in the cache and
reused, eliminating the need to verify the class and create a new JVAPGM (and eliminating the time and
performance impact that would be required for these actions). Older JVAPGMs are "aged out" of the
cache if they are not used within a given period of time (default is one week).
In general, the only cost of enabling the verification cache is a modest amount of disk space. If it turns out
that your application is not using one of the problem user class loaders, the cache will have no impact,
positive or negative, while if your application is using such a class loader then the time taken to create
and cache the persistent JVAPGM is only slightly more than the time required to create a temporary
JVAPGM. With next to zero downside risk, and a decent potential to improve performance, the
verification cache is well worth a try.
Maintenance is not a problem either: if the source for a cached JVAPGM is changed, the currently-cached
version will simply "age out" (since its class will no longer be a byte-for-byte match), and a new
JVAPGM will be silently created and cached. Likewise, the cache doesn't care about JDK versions, PTFs
installed, application upgrades, etc.
7.5 Determining Which JVM to Use
Beginning in V5R4, applications can run in either the Classic 64-bit VM or with IBM Technology for
Java (32-bit only in V5R4, 32-bit or 64-bit in V6R1). Both VM implementations provide a fully
compliant implementation of the Java specifications, and pure Java applications should be able to run
without changes in either VM by setting the JAVA_HOME environment variable appropriately. (See
InfoCenter for details on specifying which VM will be used to execute a Java program.) However, some
applications may have dependencies which will prevent them from working on one of the VM
implementations.
In general, applications should use 32-bit IBM Technology for Java when possible. Applications which
require larger heaps than can be managed with a 32-bit VM should use 64-bit IBM Technology for Java
(on V6R1). The Classic VM also remains available for cases where IBM Technology for Java is not
appropriate and to ease migration from older releases.
Some factors to consider include:
Functional Considerations
1. IBM Technology for Java was introduced in i5/OS V5R4M0. Older versions of OS/400 and i5/OS
support only the Classic VM.
2. IBM Technology for Java only supports Java 5.0 (JDK 1.5) and higher. Older versions of Java (1.4,
1.3, etc.) are not supported. While the Java versions are generally backward compatible, some
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 7 - Java Performance
132
