Storage heaps in a JVM

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:

System heap
The main system heap contains the class definitions for all the system classes and standard extension classes, and for the middleware classes. It also contains the pooled string constant data, and it might contain some system class objects that persist for the lifetime of the JVM. For continuous JVMs and single-use JVMs, the system heap is also used for items that would be contained in the application-class system heap for a resettable JVM. (How JVMs are reused explains the differences between these types of JVM.)
Application-class system heap
The application-class system heap, or ACS heap, is intended to contain objects which persist for the lifetime of the JVM (that is, they are kept across JVM reuses) and which are reinitialized if the JVM is reset. Continuous JVMs and single-use JVMs do not have an application-class system heap, because these types of JVM are not reset after each use; only resettable JVMs have an application-class system heap.

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.

Nonsystem heap
This storage heap comprises two other storage heaps of variable size:
Middleware heap
The middleware heap contains objects constructed by middleware classes, and any objects constructed by system classes as a result of calls from middleware classes. It also contains static data for the middleware classes and the system classes, and other string constant data. The objects in this storage heap have a lifetime that is greater than a single transaction, so they are kept across JVM resets. For continuous JVMs and single-use JVMs, the middleware heap is also used for items that would be contained in the transient heap for a resettable JVM.
Transient heap
The objects in this storage heap are intended to have a lifetime that is the same as the transaction using the JVM. Continuous JVMs and single-use JVMs do not have a transient heap, because these types of JVM are not reset after each use; only resettable JVMs have a transient heap.

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.

Figure 1. JVM storage heap allocations within a Language Environment enclave
The illustration shows how storage in the Language Environment enclave is allocated to the nonsystem heap, the application-class system heap, and the system heap itself. The text above the figure explains how this is done.

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.