Caching classes previously loaded by a user class loader

Caching classes previously loaded by the i5/OS Java virtual machine (JVM) user class loaders can reduce the amount of time that it takes to load servlets, JavaServer Page files and enterprise beans. Caching classes is not required for most applications. However, in some situations, caching classes improves an application's performance. Application server class loaders, application class loaders, and application module class loaders load WebSphere Application Server components such as servlets, JSP files and enterprise beans. These class loaders are called user class loaders in the i5/OS documentation.

If servlets, JSP files or enterprise beans in your application are slow to load, a cache is available to improve the startup performance of these components. The cache enables the i5/OS JVM to identify classes previously loaded with user class loaders.

When the cache is enabled, each Java program object (JVAPGM) created by a user class loader is cached for reuse during the initial class loading. The first time the class is loaded, the loading is slow because JVAPGMs are created and bytecode is verified during the loading. After a class is in the cache, JVAPGM creation and bytecode verification does not occur, which makes subsequent loadings much quicker. You must run your application to initially add the classes to the cache.

Before attempting to enable the cache, determine whether using the cache might enhance the performance of your components. You should only enable the cache if your components are slow to load in the following situations:

Your application contains these components	The components load at this time	Comments
Servlets that are configured to load when an application server starts or enterprise beans	When the application server starts up	Having a large number of these components, or complex components that access many classes in your application, slows application server startup.
Servlets that are not configured to load when an application server starts or JSP files	When classes of the component are first accessed	If these components are complex or access many classes in your application, it takes longer to load these components for the first time.

Overview

Procedure

1. In the administrative console, click Servers > Application Servers > server_name > Process Definition > Java Virtual Machine > Custom Properties.

2. Under Server Infrastructure, click Java and Process Management > Process Definition > process_name > Java Virtual Machine.

3. Under Additional Properties, click Custom Properties > New.

4. Specify os400.define.class.cache.file in the Name field and the full path name of a valid Java archive (JAR) file to hold the Java Program objects (JVAPGMs) in the Value field. The os400.define.class.cache.file custom property enables the Java user class loader cache. The JAR file specified in the Value field must contain a valid JAR entry, but does not have to have any other content beyond the single member required to make the JAR command function.

   The /QIBM/ProdData/Java400/QDefineClassCache.jar cache JAR file is shipped with WebSphere Application Server. You can use this JAR file as is, or copy and rename it. You can also create your own cache JAR file:

   1. Enter the STRQSH command to start the Qshell.

   2. Switch to the directory where you want the JAR file located. Make the directory first, if necessary.

      mkdir /cache cd /cache

   3. Create a dummy file to place in the JAR. Use any name. This example uses example:

      touch example

   4. Build the JAR file. This example names the JAR file MyAppCache.jar:

      jar -cf MyAppCache.jar example

   5. Clean up the dummy file:

      rm example

   This JAR file must not be on any classpath.

   You can use DSPJVAPGM on this JAR file to determine how many JVAPGMs are cached. The Java programs field of the DSPJVAPGM display indicates how many JVAPGMs are cached, and the Java program size field indicates how much storage is consumed by cached JVAPGMs. Other fields of the display are meaningless when DSPJVAPGM is applied to a JAR file used for caching.

   You can also use CHGJVAPGM on the JAR file to change the optimization of the classes in the cache. CHGJVAPGM only affects programs currently in the cache. Classes added to the cache are optimized according to the other properties described in this list.

   Name	Example value
   os400.define.class.cache.file	/QIBM/ProdData/Java400/QDefineClassCache.jar

5. Click OK.

6. Optional: Click New again and specify one of the following custom properties to customize the user class loader cache. Repeat this step as many times as necessary to complete your customization.

   os400.define.class.cache.hours

   Optionally, specify the number of hours an unused JVAPGM persists in the cache. When a JVAPGM has not been used and this timeout is reached, the JVAPGM is removed from the cache. The default value is 168 (one week). The maximum value is 9999 (about 59 weeks).

   os400.define.class.cache.maxpgms

   Optionally, specify the maximum number of JVAPGMs the cache can hold. If this value is reached, the least recently used JVAPGMs are replaced first. The default value is 5000. The maximum value is 40000.

   For example, to use the shipped cache JAR with a maximum of 10,000 JVAPGMs that have a maximum life of 1 year, add the specify the following custom propertie:

   Name	Value
   os400.define.class.cache.hours	8760
   os400.define.class.cache.maxpgms	10000

   Other Java system properties, such as os400.defineClass.optLevel, can be used to customize how JVAPGMs are created in the cache.

7. Click OK and then click Save to save the configuration changes.

8. Restart the application server.

Results

Related tasks