Language Environment enclave storage for JVMs

A JVM server has both static and dynamic storage requirements, primarily in 64-bit storage. It may use a significant amount of 31-bit storage.

Note: The amount of 31-bit storage used will depend on several factors:
  • The configuration parameters
  • The design and use of other products
  • The design of the JVM
  • The Java™ workload.

For example, the use of -Xcompressedrefs might improve performance, but requires 31-bit storage and should always be used with -XXnosuballoc32bitmem to ensure that the JVM dynamically allocates 31-bit storage for compressed references based on demand. For more information about of these options, see Default settings for the JVM in IBM SDK, Java Technology Edition 7.0.0. Just-in-time compilation (JIT) also requires 31-bit storage for the compiled class code.

A JVM runs as a z/OS® UNIX System Services process in a Language Environment® enclave that is created using the Language Environment preinitialization module, CELQPIPI.

JVM storage requests are handled by Language Environment, which in turn allocates z/OS storage based on the defined runtime options.

The Language Environment runtime options are set by DFHAXRO. The default values provided by these programs for a JVM enclave are shown in Table 1:
Table 1. Language Environment runtime options used by CICS for the JVM enclave
Language Environment runtime options Example JVM server values
Heap storage 
HEAP64(256M,4M,KEEP,4M,1M,FREE,1K,1K,KEEP)
Library heap storage 
LIBHEAP64(5M,3M)
Library routine stack frames that can reside anywhere in storage 
STACK64(1M,1M,16M)
Optional heap storage management for multithreaded applications (64 bit) 
HEAPPOOLS64(ALIGN)
Optional heap storage management for multithreaded applications (31 bit) 
HEAPPOOLS(ALIGN)
Amount of storage reserved for the out-of-storage condition and the initial content of storage when allocated and freed 
STORAGE(NONE,NONE,NONE)
Note: For current JVM server values, refer to the DFHAXRO member in Library SDFHSAMP.

Language Environment runtime options, such as HEAP64, work on the principle of an initial value for that type of storage: for example, 256 MB 64-bit. When HEAP64 cannot contain a new request, an increment is allocated of the specified size (4 MB above) or of the request size plus control information, whichever is larger. Extra increments are allocated as required to meet demand. When an increment is empty, Language Environment will either KEEP or FREE the z/OS storage based on the runtime value.

For full information about Language Environment runtime options, see z/OS Language Environment Customization.

Where possible, the 31-bit and 64-bit initial size should cover the total 31-bit and 64-bit storage requirements, although a few increments is acceptable. This reduces both overall z/OS storage requirements and CPU time, compared to when there are many increments.

The HEAP64 31-bit increment size should not be set to less than 1M and the FREE option should be used. In the previous example, the 31-bit parameters were set to 4M, 1M, and FREE.

Language Environment 31-bit and 64-bit HEAP usage can be seen by activating the RPTO(ON) and RPTS(ON) options in DFHAXRO. An Language Environment storage report is produced when the JVM server is stopped.

You can override the Language Environment runtime options by modifying and recompiling the sample program DFHAXRO, which is described in Modifying the enclave of a JVM server with DFHAXRO. This program is set on the JVMSERVER resource, so you can use different names, which is why there are different options for individual JVM servers, if required.

The amounts of storage required for a JVM in a Language Environment enclave might require changes to installation exits, IEALIMIT or IEFUSI, which you use to limit the REGION and MEMLIMIT sizes. A possible approach is to have a Java owning region (JOR), to which all Java program requests are routed. Such a region runs only Java workloads, minimizing the amount of CICS® DSA storage required and allowing the maximum amount of MVS™ storage to be allocated to JVMs.