uCosminexus Application Server, Expansion Guide
![[Contents]](FIGURE/CONTENT.GIF)
![[Index]](FIGURE/INDEX.GIF)
![[Back]](FIGURE/FRONT.GIF)
The process of releasing the Explicit memory block when the automatic release functionality is enabled, is executed for the Explicit memory blocks that are reserved in advance by automatic release reserving and explicit release reserving. The release processing deletes the unnecessary Explicit memory blocks from the memory.
Note that if the objects that are being referenced from outside (Explicit memory blocks which are not targeted for releasing) exist, the objects are moved to a new Explicit memory block.
- Organization of this subsection
- (1) Execution timing
- (2) Executed details
(1) Execution timing
JavaVM executes it in the same garbage collection in which reserving for release is executed by automatic release reserving.
(2) Executed details
The executed details are same as in the case of the processing of releasing the Explicit memory block when the automatic release functionality is disabled, except for the behavior of objects that are being referenced from the Explicit memory blocks, which are not targeted for releasing. For the details that are executed in the process of releasing Explicit memory blocks, see 8.8.2 The process of releasing the Explicit memory block when the automatic release functionality is disabled.
In the case of the following conditions, the operation will be different.
- In the case you cannot secure free space in the Explicit memory block
This corresponds to the case when there is no free space in the placement destination Explicit memory block for placing objects targeted for placement at the time of placing objects in the Explicit memory block. In such cases, you cannot place an object in the Explicit memory block. The objects, which cannot be placed, are placed in the Java heap area.
- If the Java heap overflows when moving objects to the Java heap
This corresponds to the case when objects cannot be moved because the area of the Explicit memory block cannot be secured and there is no free space in the movement destination Java heap when the object moves to the Java heap. In such cases, the full garbage collection is executed and free space is secured in the Java heap. After the execution of the full garbage collection, the object is moved to the Java heap.
If you cannot secure the free space required to move the Java objects even after you execute the full garbage collection, a log file is output and the objects are again placed in the Explicit memory blocks. For details on the log files that are output, see 4.19 Event log in the Explicit Memory Management functionality in the uCosminexus Application Server Maintenance and Migration Guide.
- If you cannot create sufficient free space with the full garbage collection
This corresponds to the case when there is no free space in the Java heap and you cannot secure free space required to move Java objects even by executing the full garbage collection. In such cases, JavaVM aborts as it does in the case of an insufficient C heap. However, in the case of an insufficient C heap, the required memory size is output as nnn in the prompt request nnn bytes. When JavaVM aborts, 0 is always output as nnn.
All Rights Reserved. Copyright (C) 2013, 2015, Hitachi, Ltd.