7.13.6 Checks and measures when the automatic release processing of the Explicit memory block takes a long time

This subsection describes the checks and measures when the automatic release processing of the Explicit memory block takes a long time.

The automatic release processing of the Explicit memory block occurs concurrently with the garbage collection, and the processing of the J2EE server stops during the automatic release processing. Therefore, if the automatic release processing takes a long time, problems might occur in the system.

If an Explicit memory block with a large size (called large block hereafter) is generated, the automatic release processing takes a long time. A large block might be generated if the objects that are not called back even with a full garbage collection, such as the objects that are used until an application stops, are allocated to the Explicit heap. Therefore, you must prevent the generation of a large block by allocating the objects that must not be allocated to the Explicit heap, to the Java heap. For details on the event in which a large block is generated and the automatic release processing takes time, see 8.10.2 Mechanism for reducing the time taken for the automatic release processing, and Appendix B.1 Effect on the automatic release processing of the Explicit memory block in the uCosminexus Application Server Expansion Guide.

From the content of the thread dump, you can check whether a large block is being generated.

If a large block is generated, follow the below procedure to specify settings to allocate the objects responsible for the large block to the Java heap.

Action

  1. Applying the functionality for controlling the transfer of objects to the Explicit memory block
  2. Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality
  3. Identifying the objects responsible for a large block and preventing the transfer of those objects to the Explicit heap
  4. Re-tuning the Java heap area and Explicit heap area

This subsection describes how to check whether a large block is being generated and the action to be taken.

Organization of this subsection
(1) Checking whether a large block is being generated
(2) Applying the functionality for controlling the transfer of objects to the Explicit memory block
(3) Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality
(4) Identifying the objects responsible for a large block and preventing the transfer of the objects to the Explicit heap
(5) Re-tuning the Java heap area and Explicit heap area

(1) Checking whether a large block is being generated

Execute the eheapprof command to check the Explicit heap information output to the thread dump.

An example of output is as follows:

"NULL" eid=1(0x1000000000123456​)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
"NULL" eid=2(0x1000000000223456​)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
"ReferenceExplicitMemory-2" eid=3(0x1000000000323456​)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable

Note: NULL in the name of the Explicit memory block indicates that the automatic release processing was implemented once, for this Explicit memory block.


The total part in bold indicates the allocated memory size of the Explicit heap.

In this example, the memory size described in total for each Explicit memory block indicates that the Explicit memory block eid=2 is 153,744 KB, and is extremely large compared to the 112-KB Explicit memory blocks eid=1 and eid=3. This indicates that a large block has been generated and that this block is the Explicit memory block eid=2.

(2) Applying the functionality for controlling the transfer of objects to the Explicit memory block

Check the transition in the usage status of the Explicit heap using the event log of the Explicit Memory Management functionality. For details on how to check the transition in the usage status of the Explicit heap, see 7.13.2 Investigating the transition in the usage status.

An example of output is as follows:

[ENS]<Thu Oct 21 14:55:50 2007>[EH: 12672K->172032K(172032K/196608K)][E/F/D: 200/0/0][cause:Full GC][CF: 0]
[ENS]<Thu Oct 21 14:55:50 2007>[EH: 172032K->172032K(172032K/196608K), 0.1124626​ secs][E/F/D: 200/0/0]\
[DefNew::Eden: 0K->0K(243600K)][DefNew::Survivor: 0K->0K(17400K)][Tenured: 103400K->103400K(556800K)]\
[target:584K/0K/584K][cause:Migrate]

The part beginning with EH: in bold indicates the usage status of the Explicit heap.

In this example, the first line is the log that is output when a full garbage collection (Full GC) occurs, as indicated in the part that begins with cause:, and the second line immediately after this is the log that is output during the automatic release processing (Migrate) of the Explicit memory block. This indicates that the automatic release processing occurred immediately after the full garbage collection. The part beginning with EH: in the log on the first line indicates that the used size of the Explicit heap before the full garbage collection occurred is 12,672 KB, the used size after the full garbage collection occurs is 172,032 KB, and that the used size of the Explicit heap has increased considerably. Note that if such an event (great increase in the used size of the Explicit heap) does not occur, proceed to step (3).

If the used size of the Explicit heap increases considerably during a full garbage collection, as described in this example, specify 1 in the -XX:ExplicitMemoryFullGCPolicy option, and apply the functionality for controlling the transfer of objects to the Explicit memory block. If you apply this functionality, the objects based on a reference relationship are no longer transferred to the Explicit memory block during a full garbage collection. For details on the functionality for controlling the transfer of objects to the Explicit memory block, see 8.10 Reducing the time taken for the automatic release processing of the Explicit memory block in the uCosminexus Application Server Expansion Guide.

Proceed to step (5) if you can prevent the generation of a large block by applying this functionality, or proceed to step (3) if a large block is still being generated.

(3) Applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality

If the following events occur, specify the -XX:+ExplicitMemoryUseExcludeClass option to apply the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality.

If you apply the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the objects of a specific class are no longer transferred to the Explicit heap. The objects of a specific class indicate the objects of the classes coded in the exclusion configuration file for the Explicit Memory Management functionality provided with the system (sysexmemexcludeclass.cfg). For details on the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, see 8.10 Reducing the time taken for the automatic release processing of the Explicit memory block in the uCosminexus Application Server Expansion Guide.

Proceed to step (5) if you can prevent the generation of a large block by applying this functionality, or proceed to step (4) if a large block is still being generated.

(4) Identifying the objects responsible for a large block and preventing the transfer of the objects to the Explicit heap

If a large block is being generated even after applying the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality in step (3), the large block might be generated by the transfer of the following objects to the Explicit heap. From among these objects, the objects that continue to survive are not called back with the automatic release processing of the Explicit memory block.

Therefore, the Explicit Memory Management functionality is not effective even if the objects that are not called back within a fixed period are allocated to the Explicit heap, so allocating the objects to the Java heap (Tenured area) is more appropriate. From among the objects, identify the objects responsible for a large block, and make sure these objects do not move to the Explicit heap.

To identify the objects responsible for a large block, check the object release ratio. The object release ratio is the percentage of objects released with the automatic release processing of the Explicit memory block. Execute the eheapprof command by specifying the -freeratio option to output the object release ratio in the Explicit heap information output in the thread dump.

An example of output is as follows:

 "NULL" eid=1(0x1000000000123456​)/B, total 112K, used 55K, garbage 0K (49.2% used/total, 0.0% garbage/used, 0 blocks) Enable
   deployed objects
   ________________Size__Instances__FreeRatio__Class________________
                  49256         10         0 [B
                   3680          4        20 package1.session.StandardManager
                  52936         14 total


 "NULL" eid=2(0x1000000000223456​)/A, total 153744K, used 144766K, garbage 0K (94.2% used/total, 0.0% garbage/used, 0 blocks) Enable
   deployed objects
   ________________Size__Instances__FreeRatio__Class________________
               77862918​     433523        10 [C
               52622946​     441714        10 java.lang.String
               12838192​      39462        35 [B
                   3680          4        20 package1.session.StandardManager
                    104          4         0 framework.ut.impl.performList
              143327840​     914707 total

 "ReferenceExplicitMemory-2" eid=3(0x1000000000323456​)/R, total 112K, used 55K, garbage 0K (49.3% used/total, 0.0% garbage/used, 0 blocks) Enable
   deployed objects
   ________________Size__Instances__FreeRatio__Class________________
                  49256          4         - [B
                   3416         10         - package3.ajp.RequestHandler
                     64          2         - java.lang.StringBuffer
                     64          1         - java.net.SocketInputStream
                     48          1         - [I
                     24          1         - [C
                  52872         19 total

#1: NULL in the name of the Explicit memory block indicates that the automatic release processing was implemented once for this Explicit memory block.

#2: [B in the class name indicates the array type of the Byte class, [C indicates the array type of the Char class, and [I indicates the array type of the Integer class.


The total part in bold indicates the allocated memory size of the Explicit heap, and the FreeRatio part indicates the object release ratio.

In this example, there are three Explicit memory blocks, eid=1, eid=2, and eid=3. The object release ratio indicated in FreeRatio of each Explicit memory block shows that the object release ratio of the Explicit memory block eid=3 is "-", and that the automatic release processing has not been executed.

First, see the memory size indicated in total for each Explicit memory block. The Explicit memory block eid=2 is 153,744 KB, and is extremely large compared to the 112-KB Explicit memory blocks eid=1 and eid=3. This indicates that the Explicit memory block eid=2 is a large block.

Next, see the object release ratio and the Explicit memory block size for each class of the objects in the large block (eid=2). In this example, there are five objects and the classes of these objects also include the classes provided in Java SE ([B, [C, and java.lang.String). In many cases, the classes provided in Java SE are transferred to the Explicit memory block referenced from the objects responsible for the large block. Therefore, if you specify settings so that the objects responsible for the large block are not transferred to the Explicit memory block, you can also prevent the transfer of the objects of the classes provided in Java SE. Also, if you set the classes provided in Java SE as the target of the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the extent of impact is wide and also results in restrictions on the objects allocated to an ideal Explicit memory block. Therefore, do not set the classes provided in Java SE as the target of the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality (however, excluding the cases in which all the objects of the classes provided in Java SE might be allocated to the Java heap) .

The classes other than those provided with Java SE include package1.session.StandardManager and framework.ut.impl.performList. The object of package1.session.StandardManager is also used in the Explicit memory block eid=1, but eid=1 is not a large block. This indicates that the objects of this class are not responsible for the large block. From this, you can identify that the object of framework.ut.impl.performList is responsible for the large block.

After identifying the object responsible for the large block, code the class of that object in the configuration file used with the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality. For details on how to specify the code in the configuration file, see 8.13.3 Controlling the application target of the Explicit Memory Management functionality using the configuration file in the uCosminexus Application Server Expansion Guide.

(5) Re-tuning the Java heap area and Explicit heap area

If you apply the object transfer control functionality and the functionality for specifying the classes to be excluded from the Explicit Memory Management functionality, the allocated area of the object changes and the memory size of the Java heap and Explicit heap also increases and decreases. Therefore, see the methods described at the following locations, and then re-tune the memory size for each area: