Java cache for user classloaders

The OS/400 JVM user classloader cache is a feature that allows the JVM to "remember" classes that have been loaded with user classloaders. This feature improves the startup performance of classes loaded by user class loaders by allowing the JVAPGMs created by user classloaders to be cached for reuse, avoiding JVAPGM creation and bytecode verification during the initial class load. WebSphere components (servlets, JSPs and enterprise beans) are loaded by user classloaders and can take advantage of this feature.

For most applications, the default WebSphere setup provides the best solution. You should only consider the techniques described here if you are experiencing performance problems in the following areas:

• Application server startup
  These components are loaded when the application server is started:
  • servlets that are configured to load at startup
  • enterprise beans

  Having a large number of these components, or complex components that access many classes in your application, will make application server startup time longer.

• Component runtime during first-touch
  These components are loaded the first time they are accessed after the application server is started:

  • servlets that are not configured to load at startup
  • JSPs

  If these components are complex or access many classes in your application, your first-touch times of these components will be longer.

The user classloader cache improves performance in two ways:

• Avoiding bytecode verification
  If the class is already in the cache, bytecode verification will not be performed again.
• Avoiding creation of JVAPGMs
  If the class is already in the cache, the existing JVAPGM will be used. Since any optimization level can be stored in the cache, it is more practical to consider higher optimization levels than previously.

Note in both cases the first time the class is loaded (for example before the cache is primed or after a class is changed), these functions will be performed and the load will be slower. Once the class is already in the cache, these functions will not be performed, so subsequent loads will be much quicker. There is no way to prime the cache with classes other than running your application.

Use the User Classloader Cache

To enable the user classloader cache, the Java system property os400.define.class.cache.file must be specified with a valid value. Other Java system properties may be optionally specified. Use the following Java system properties to enable and customize the user classloader cache:

• os400.define.class.cache.file
  This property must be specified to enable the Java user classloader cache function. The value specifies the full path name of a valid JAR file that will hold the Java Program objects (JVAPGMs). This JAR file must contain a valid JAR entry, but need have no other content beyond the single member required to make the JAR command function. Here are two ways to create a cache JAR file.
  • V5R1 PTF 5722JV1 SI02683 installs a suitable JAR file, /QIBM/ProdData/Java400/QDefineClassCache.jar. You may use this JAR file as is, or copy and rename as desired.
  • Create your own cache JAR file as follows:
    1. Start Qshell by entering the command STRQSH.
    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. The name can be anything, 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. Cleanup the dummy file

       rm example
       

    The value of the os400.define.class.cache.file property would be /cache/MyAppCache.jar.

  This JAR file must not be on any classpath.

  DSPJVAPGM can be used 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.

  CHGJVAPGM can be used on this 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 will be optimized according to the other properties below.

  os400.define.class.cache.hours
  Specifies how long (in hours) an unused JVAPGM persists in the cache. When a JVAPGM has not been used and this timeout is reached, the JVAPGM will be removed from the cache. The default value is 168 (one week). The maximum value is 9999 (about 59 weeks).

  os400.define.class.cache.maxpgms
  Specifies the maximum number of JVAPGMs the cache can hold. If this value is reached, the least recently used JVAPGMs will be replaced first. The default value is 5000. The maximum value is 40000.

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

To add Java system properties to an application server, perform these steps:

1. In the administrative console select Servers and then Application Servers.
2. Click on the application server you want to modify.
3. In the Additional properties section, click Process Definition.
4. In the Additional properties section, click Java Virtual machine.
5. In the Additional properties section, click Custom Properties.
6. Click New to add a property.

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

Property	Value
os400.define.class.cache.file	/QIBM/ProdData/Java400/QDefineClassCache.jar
os400.define.class.cache.hours	8760
os400.define.class.cache.maxpgms	10000