7.14.3 Checking and measures when there is an overflow from the Explicit heap

This point describes the measures to be taken and how to check when there is overflow of Explicit heap.

An overflow of Explicit heap indicates the following state:

State where Explicit heap was used up to the maximum size
State where OS failed to allocate memory when the Explicit memory block is extended

When there is an overflow of the Explicit heap, the sub-state of Explicit memory block, whose area is tried to be extended, changes from Enable to Disable. You cannot deploy the object in Explicit memory block which is in the Disable state.

You can check whether there is an overflow of Explicit heap by checking the event log of the Explicit Memory Management functionality or by checking the contents of thread dump. Moreover, you can also check through the information acquired by JavaAPI.

When there is an overflow of Explicit heap, take the following measures:

Measures to be taken when Explicit heap overflows

Increase the maximum size of Explicit heap.

Change the specifications of the -XX:HitachiExplicitHeapMaxSize option.
If there is an overflow of Explicit heap when the maximum size of Explicit heap is not achieved, increase the memory size that can be allocated from OS

Increase the memory size that can be used by the Application Server.
Eliminate the cause responsible for consuming large amount of Explicit heap.

These points describe about how to check an overflow from Explicit heap.

Organization of this subsection

(1) Investigating the event log of the Explicit Memory Management functionality
(2) Investigating from the log file output by the thread dump
(3) Investigation from the API of Java

(1) Investigating the event log of the Explicit Memory Management functionality

To investigate with the event log of the Explicit Memory Management functionality, you must specify normal in the -XX:HitachiExplicitMemoryLogLevel option of JavaVM in advance. As a result, whenever the GC occurs, the use status of Explicit block will be output to the event log of the Explicit Memory Management functionality.

An output example is as follows:

[ENS]Thu Oct 21 14:55:50 2007[EH: 12672K->12800K(12800K/65536K)][E/F/D: 200/0/0][cause:GC][CF: 0]

The part that is highlighted and bolded indicates the number of Explicit memory blocks. E and D indicate Enable and Disable which are the sub-states of Explicit memory block. When the Explicit memory block is in the Disable state, there is an overflow of Explicit heap. In this example, it is concluded that there are 200 Explicit memory blocks in Enable state and nil in Disable state. Furthermore, when the Explicit memory block is Disable, check for relation with the Explicit heap maximum size. When there is extra Explicit heap maximum size, it can be concluded that the OS fails to allocate the memory.

Moreover, when verbose is specified in the -XX:HitachiExplicitMemoryLogLevel option of JavaVM, the factors responsible for changing the sub-state of Explicit memory block to Disable state, is also output.

An output example is as follows:

[EVO]Tue Jul 24 01:23:51 2007[alloc failed(Disable)][EH: 32760K(0K)/32768K/65536K][E/F/D: 321/0/1][cause:GC]\
["BasicExplicitMemory-3" eid=3/B: 128K(0K)/128K][Thread: 0x00035a60]
[EVO][Thread: 0x00035a60] at ExplicitMemory.newInstance0(Native Method)
[EVO][Thread: 0x00035a60] at BasicExplicitMemory.newInstance(Unknown Source)
[EVO][Thread: 0x00035a60] at AllocTest.test(AllocTest.java:64)
[EVO][Thread: 0x00035a60] at java.lang.Thread.run(Thread.java:2312)

Above is the example showing the overflow of Explicit heap.

Of the parts that are highlighted and bolded, [alloc failed(Disable)] indicates the reason the Explicit memory block entered the Disable sub-status. "BasicExplicitMemory-3" eid=3/B: 128K(0K)/128K indicates the information of Explicit memory block that is in Disable state. Moreover, the rows starting with [EVO][Thread: 0x00035a60] indicates the stack trace when the event has occurred. However, when there is an overflow of Explicit heap due to the transition of object by GC, the stack trace is not output.

To Page Top

(2) Investigating from the log file output by the thread dump

You can output the sub-state of each Explicit memory block by the output of the thread dump using the cjdumpsv command.

The output example is as follows:

Explicit Heap Status
--------------------
 max 65536K, total 21888K, used 20992K, garbage 1288K (32.0% used/max, 95.9% used/total, 6.1% garbage/used), 2 spaces exist
 
 Explicit Memories(0x12345678)
 
 "EJBMgrData" eid=1(0x02f25610)/R, total 21376K, used 20480K, garbage 1234K (95.8% used/total, 6.0% garbage/used, 0 blocks) Enable
 
 "ExplicitMemory-4" eid=4(0x02f45800)/B, total 512K, used 512K, garbage 54K (100.0% used/total, 10.5% garbage/used, 0 blocks) Disable

Parts that are highlighted and bolded indicate the sub-status of each Explicit memory block.

To Page Top

(3) Investigation from the API of Java

You can investigate the sub-state of the Explicit memory block using the following methods:

JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.isActive()
JP.co.Hitachi.soft.jvm.MemoryArea.ExplicitMemory.isReclaimed()

If the return value of both methods is false, the sub-state of the Explicit memory block can be determined as Disable.

To Page Top