Adjusting the size of the shared class cache

When the master JVM initializes the shared class cache, the amount of storage in the cache is fixed. When the storage in the shared class cache becomes full, worker JVMs cannot add any more classes to it, and the JIT compiler might not be able to carry out any further processing of the classes that are already loaded. You can use the CEMT INQUIRE CLASSCACHE command (or the equivalent EXEC CICS command) to report on the size of the shared class cache (CACHESIZE), and the amount of free space within it (CACHEFREE, which is part of the extended display for the shared class cache in CEMT).

Use the system initialization parameter JVMCCSIZE to specify the initial setting for the size of the shared class cache. The default is 24MB.

The size that you specify for the shared class cache needs to be sufficient to contain: Bear in mind that the JIT-compiling process happens at variable times during the execution of your applications. To identify the total size of the classes and JIT-compiled code for an application, run the application repeatedly in a development environment, using the shared class cache. While you are running the application, monitor the amount of free space in the shared class cache, which is reported by the CACHEFREE parameter on the CEMT INQUIRE CLASSCACHE command (or the equivalent EXEC CICS command). After a sufficient number of uses of the application (perhaps around one thousand), you should find that the amount of free space has stabilised, meaning that the JIT-compiling process is largely complete. Repeat this process for each application that will be using the shared class cache. Add together the amount of storage used by each application, and add on a suitable safety margin (to allow for any late JIT-compiling or future application changes), to arrive at an approximate size for the shared class cache.

If the storage in your shared class cache becomes full, worker JVMs can continue to use the classes and compiled code that are already present in it. However, if a worker JVM subsequently tries to add a new class or the results of JIT-compilation to the shared class cache, the worker JVM throws a java.lang.OutOfMemoryError. If you find that this is happening, you need to increase the size of the shared class as soon as possible.

If you have made the initial size of the shared class cache too small (or too large), there are two ways to change it without changing the system initialization parameter:
  1. When the status of the shared class cache is STARTED, you can use the CEMT PERFORM CLASSCACHE RELOAD command (or the equivalent EXEC CICS command) to create a new shared class cache. The RELOAD option does not work if the shared class cache has not been started. Specify the size for the new shared class cache by using the CACHESIZE option on the command. This causes the least disruption to worker JVMs that are using the shared class cache.
  2. When the status of the shared class cache is STOPPED (either because it has not yet been started on this CICS execution, or because you have stopped it manually), you can use the CEMT PERFORM CLASSCACHE START command (or the equivalent EXEC CICS command) to start the shared class cache. Specify the size for the new shared class cache by using the CACHESIZE option on the command. If you do not want the shared class cache to remain active, you can then shut it down again (see Terminating the shared class cache).

When you specify a new size for the shared class cache while CICS is running, subsequent CICS restarts use the new value, unless the system is INITIAL or COLD started, or the JVMCCSIZE system initialization parameter is specified as an override at startup. In these cases, the value from the JVMCCSIZE system initialization parameter is used.