Filter
Top Products
display; rates of 20 to 30 faults per second are usually acceptable, but larger values may indicate a
performance problem. In this case, the size of the memory pool should be increased, or the collection
threshold value (GCHINL or -Xms) should be decreased so the heap isn’t allowed to grow as large. In
many cases the scenario may be complicated by the fact that multiple applications may be running in the
same memory pool. Therefore, the total memory requirements of all of these applications must be
considered when setting the pool size. In some environments it may be useful to run key Java
applications in a private pool in order to have more control over the memory available to these
applications.
In some cases it may also be helpful to set the maximum heap size to be slightly larger than the memory
pool size. This will act as a safety net so that if the heap does grow beyond the memory pool size, it will
not cause high paging rates. In this case, the application will probably not be usable (due to the
synchronous garbage collection cycles and OutOfMemoryErrors that may occur), but it will have less
impact on any other applications running on the system.
A final consideration is the application’s use of objects. While the garbage collector will prevent certain
types of memory leaks, it is still possible for an application to have an “object leak”. One common
example is when the application adds new objects to a List or Map, but never removes the objects.
Therefore the List or Map continues to grow, and the heap size grows along with it. As this growth
continues, the garbage collector will begin taking longer to run each cycle, and eventually you may
exhaust the physical memory available to the application. In this case, the application should be modified
to remove the objects from the List or Map when they are no longer needed so the heap can remain at a
reasonable size. A similar example involves the use of caches inside the application. If these caches are
allowed to grow too large, they may consume more memory than is physically available on the system.
Using smaller cache sizes may improve the performance of your application.
Bytecode Verification
In order to maintain system stability and security, it is important that Java bytecodes are verified before
they are executed, to ensure that the bytecodes don’t try to do anything not allowed by the Java VM
specification. This verification is important for any Java implementation, but especially critical for server
environments, and perhaps even more so on i5/OS where the JVM is integrated into the operating system.
Therefore, in i5/OS, bytecode verification is not only turned on by default, but it is impossible to turn it
off. While the bytecode verification step isn’t especially slow, it can impact startup time in certain cases
– especially when compared to VMs on other platforms which may not do bytecode verification by
default. In most cases, full bytecode verification can be done just once for a class, and the resulting
JVAPGM objects saved with its corresponding class or jar file as long as the class doesn’t change.
However, when user classloaders are used to load classes, the VM may not be able to locate the file from
which the class was loaded (in particular, if the standard URLClassLoader mechanism is not being used
by the user classloader). In this case, the bytecode verification cache is used to minimize the cost of
bytecode verification.
In V5R3 and later the bytecode verification cache is enabled by default, and tuning is usually
unnecessary. In V5R2 and earlier releases the cache was disabled by default, and tuning was sometimes
necessary. The cache can be turned on by specifying a valid value (e.g.,
/QIBM/ProdData/Java400/QDefineClassCache.jar) for the os400.
define.class.cache.file system
property. It may also be helpful to set
os400.define.class.cache.maxpgms to a value of around
20000, since the default of 5000 had been shown to be too small for many applications. In V5R3 and
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
© Copyright IBM Corp. 2008 Chapter 7 - Java Performance 131