7.1.2 Configuring the memory space used in JavaVM and the JavaVM options

This subsection explains the configuration of the memory space used in JavaVM and the JavaVM options.

JavaVM uses two types of memory space; JavaVM specific area and OS specific area.

The following figure shows the configuration of the memory space used by JavaVM. The numbers in the figure correspond to the numbers in Table 7-1.

Figure 7-7 Configuration of memory space used by JavaVM

[Figure]

The respective areas are explained below. The area formed by combining the Eden area, the Survivor and the Tenured area is called the Java heap.

Eden area
Java objects that are created by new are initially stored in the DefNew::Eden area.
Survivor area
Among the Java objects stored in the New area, the DefNew::Survivor area stores those Java objects that are not destroyed when copy garbage collection is executed. The From space and the To space configure the Survivor area. The size of the From space and the To space is same.
Tenured area
The Tenured area is a memory space that stores Java objects that are considered to be necessary for a longer duration. The Java objects for whom a copy garbage collection is executed more than the specified number of times in the Survivor area and that were not destroyed, are moved to this area.
Permanent area
The Permanent area stores the information of class that has been loaded.
Explicit heap area
The Explicit heap area stores Java objects for which a full garbage collection is not executed. The Explicit heap area is the JavaVM-specific memory space and the Explicit heap area is allocated only when using the Explicit Memory Management functionality.
C heap area
The C heap area is used by JavaVM. The C heap is also used by the native library that is called by JNI.
Reference note
Maximum size of the C heap area (In AIX)
In AIX, when you use the JNI to execute the program for invoking JavaVM, set up the maximum size of the C heap area with one of the following methods. If no method is specified, the default value of the shell datasize resource becomes the maximum size of the C heap area.
  • Specify the C heap area size in the value of the datasize resource in shell, and then execute the program.
    For csh (C shell): limit datasize C-heap-area-size
    For sh (default shell) and ksh: ulimit -d C-heap-area-size
  • Specify -bmaxdata: C-heap-area-size in the linkage option for program generation.
  • Specify the MAXDATA value in the environment variable LDR_CNTRL, and then execute the program.
    For csh (C shell): setenv LDR_CNTRL MAXDATA=C-heap-area-size
    For sh (default shell) and ksh: export LDR_CNTRL=MAXDATA=C-heap-area-size
  • Use the setrlimit() system call to implement the processing for setting up the C heap area size from within a program.

The examples includes the following area:
Code cache area
This area stores the JIT compilation code generated by JIT compilation.
JavaVM speeds up the processing by JIT compiling and executing the Java methods with a large invocation count and loop count.
Reference note
Maximum size of the code cache area
Specify the maximum size of the code cache area in the ReservedCodeCacheSize option.
Specify a value greater than the default value in the ReservedCodeCacheSize option. For details on the default value, see 16.4 Default values of the Java HotSpot VM options that can be specified with Application Server in the uCosminexus Application Server Definition Reference Guide.
Also, if the code cache area has depleted or might deplete, consider extending the code cache area.
Note the following points when you extend the code cache area:
  • You cannot estimate the size of the JIT compilation code by calculation. Therefore, actually measure the amount of the code cache area used in the Java application execution environment, consider the amount of the code cache area (maximum 500 KB for 32 bit, and maximum 2 MB for 64 bit) to be used by the system, and then estimate the maximum size of the code cache area.
  • For estimating the usage of the virtual memory, see 5.3 Estimating virtual memory usage or 6.3 Estimating virtual memory usage.
Stack area
Stack area for Java threads.
Reference note
Stack area size of the main thread
To change the stack area size of the main thread, set up a value greater than the value specified in -Xss.

The following table describes the JavaVM options that specify the size and ratio of the respective areas. The numbers in the table correspond to the numbers in Figure 7-7.

Table 7-1 JavaVM options for specifying the size and ratio of the JavaVM memory space

No.Option nameMeaning of the option
1-XmxsizeSets the maximum size of Java heap.
2-XmssizeSets the initial size of Java heap.
3-XX:MaxPermSize=sizeSets the maximum size of the Permanent area.
4-XX:PermSize=sizeSets the initial size of the Permanent area.
5-XmnsizeSets the initial value and the maximum value of the New area.
6-XX:[+|-]HitachiAutoExplicitMemoryAllocates the memory used in Explicit memory block when starting the JavaVM using automatic allocation function.#
7-XX:HitachiExplicitHeapMaxSize=sizeSets the maximum size of the Explicit heap area#.
8-XsssizeSets the maximum size of one stack area.
9-XX:ReservedCodeCacheSize=sizeSets the maximum size of the code cache area from among the areas used by JavaVM.
10-XX:NewRatio=valueSets the ratio of the Tenured area with respect to the New area.
If the value is 2, the ratio of the New area and the Tenured area becomes 1:2.
11-XX:SurvivorRatio=valueSets the ratio of the Eden area with respect to From space and To space of the Survivor area.
If 8 is set in value, the ratio of the Eden area, From space, and To space becomes 8:1:1.
12-XX:TargetSurvivorRatio=valueSets a target value for the ratio occupied by the Java objects in the Survivor area after a copy garbage collection is executed.
13-XX:MaxTenuringThreshold=valueSets the maximum value for frequency of switching the Java objects in the From space and To space, when executing a copy garbage collection.
The Java objects, for which the frequency of switching exceeds the set number of times, are moved to the Tenured area.
Note:
The unit of size is bytes.
#
The prerequisite options for using the explicit management heap functionality must be enabled. For details, see 7.10. Explicit heap tuning.

Reference note
Set the JavaVM options at the following places:

Table 7-2 Location for setting the JavaVM options

TargetHow to setLocation for setting
J2EE serverSmart Composer functionality
Definition file
Easy Setup definition file
Setup target
Logical J2EE server (j2ee-server)
Parameter name
add.jvm.arg
Batch serverSmart Composer functionality
Definition file
Easy Setup definition file
Setup target
Logical J2EE server (j2ee-server)
Parameter name
add.jvm.arg
SFO serverSmart Composer functionality
Definition file
Easy Setup definition file
Setup target
Logical SFO server (sfo-server)
Parameter name
add.jvm.arg
EJB Client ApplicationEdit file
Definition file
usrconf.cfg#
Parameter name
add.jvm.arg key
#
The file that is activated when the cjclstartap command is used for starting.

Hint
The default value of the respective options depends on the OS. For details about the default values of options, see 16.4 Default values of Java HotSpot VM options that can be specified in Cosminexus in the uCosminexus Application Server Definition Reference Guide.
Note
OutOfMemory occurs if any of the Java heap area, the Permanent area and the C heap area is insufficient, and as long as the memory shortage is not resolved, the state where the operations cannot be performed normally, will continue for long.
By specifying the following options when OutOfMemory occurs, the impact of OutOfMemory on the system can be reduced:

Functionality for forceful termination when OutOfMemory occurs is a functionality for forcefully terminating the J2EE server when OutOfMemory occurs due to reason such as insufficient Java heap and Perm heap. If OutOfMemory occurs due to insufficient memory in Java heap area, the Permanent area and the C heap area, this function forcefully terminates the J2EE server, and then automatically restarts it. This helps in fast recovery of a J2EE server so that that server can operate successfully.

OutOfMemory handling functionality is a functionality for which the functionality of forceful termination when OutOfMemory occurs is a prerequisite. Even if you are using the functionality of forceful termination when OutOfMemory occurs, you can continue the execution of J2EE server, if specific conditions are met by using this functionality.

If OutOfMemory occurs due to insufficient Java heap while allocating the large number of objects or while allocating huge objects in request processing, use the OutOfMemory handling functionality to continue the execution of J2EE server.

For details about the option, see -XX:[+|-]HitachiOutOfMemoryAbort (forceful termination option) and -XX:+HitachiOutOfMemoryHandling (OutOfMemory handling option) in the uCosminexus Application Server Definition Reference Guide.