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:
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 management heap 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
These points describe about how to check an overflow from Explicit heap.
To investigate with the event log of explicit management heap functionality, you must specify normal in the -XX:HitachiExplicitMemoryLogLevel option of JavaVM in advance. As a result, whenever the garbage collection occurs, the use status of Explicit block will be output to the event log of the explicit management heap 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 marked in bold indicates 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]\ |
Above is the example showing the overflow of Explicit heap.
Among the part marked in bold, alloc failed(Disable) indicates a factor responsible for changing the sub-state of Explicit memory block to Disable. "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 garbage collection, the stack trace is not output.
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 |
The part in bold indicates the sub-state of respective Explicit memory block.
You can investigate the sub-state of the Explicit memory block using the following methods:
If the return value of both methods is false, the sub-state of the Explicit memory block can be determined as Disable.