A JVM manages run-time storage in several segregated heaps. The classes described in Classes in a JVM, and the objects created by those classes, are grouped in these storage heaps according to their expected lifetime. The size of the storage heaps is determined by options in the JVM profile for a JVM. The level of reusability that you choose for the JVM affects the structure of the storage heaps in the JVM.
The storage heaps in a JVM are:
If the JVM has an application-class system heap, that heap contains the class definitions for application classes on the shareable application class path; that is, those specified by the ibm.jvm.shareable.application.class.path system property (see Classes in a JVM). It also contains class objects that represent the shareable application classes. However, it does not contain nonshareable application classes on the standard class path, that is, those specified by the CLASSPATH option in the JVM profile.
If the JVM has a transient heap, that heap contains objects constructed by shareable and nonshareable application classes, and any objects constructed by system classes as a result of calls from application classes. It also contains the class definitions and static data for any application classes on the standard class path; that is, classes that are specified by the CLASSPATH option in the JVM profile. The transient heap is completely deleted when the reset takes place. If subsequent transactions in the resettable JVM want to use the application classes that were in this heap, they must reload them from HFS files. In a continuous JVM, which does not have a transient heap, nonshareable application classes are kept intact from one JVM reuse to the next.
Figure 1 shows how the storage heaps in a resettable JVM are allocated from the Language Environment enclave heap storage, depending on the options specified in the JVM profile for the JVM.
The system heap's initial storage allocation is set by the Xinitsh option in a JVM profile. The application-class system heap's initial storage allocation is set by the Xinitacsh option in a JVM profile. These two heaps do not have a specified maximum size; they can grow until they run out of space within the Language Environment enclave.
The nonsystem heap works differently. The nonsystem heap's maximum total size is set by the Xmx option in a JVM profile. From this maximum total, storage is allocated to the transient heap and to the middleware heap. The transient heap's initial storage allocation is set by the Xinitth option in a JVM profile, and the middleware heap's initial storage allocation is set by the Xms option in a JVM profile. Both heaps can grow. The middleware heap is allocated from low storage in the nonsystem heap and expands upwards; the transient heap is allocated from high storage in the nonsystem heap, and expands down towards low storage. They can expand only until the two heaps meet—their combined total size cannot exceed the maximum size set for the nonsystem heap (the Xmx option).
Continuous and single-use JVMs do not have an application-class system heap or a transient heap, because these types of JVM are not reset after each use. For these types of JVM, the nonsystem heap consists only of the middleware heap, and therefore the Xmx option only limits the maximum size of the middleware heap.
Persistent Reusable Java™ Virtual Machine User's Guide, SC34-6201, has more detailed information about the storage heaps in a JVM.
You can tune the size of the storage heaps to achieve optimum performance for your JVMs. “Tuning storage for individual JVMs” in the CICS® Performance Guide tells you how to do this.