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:
- The classes for your applications, except for any classes on the standard
class path (the CLASSPATH option in the JVM profile), because those classes
are not placed in the shared class cache.
- The JIT-compiled code for the classes.
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:
- 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.
- 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.