uCosminexus Application Server, Expansion Guide

[Contents][Index][Back][Next]

8.8.2 The process of releasing the Explicit memory block when the automatic release functionality is disabled

The process of releasing is executed for Explicit memory blocks that are already reserved for releasing. The release processing actually deletes unnecessary Explicit memory blocks from the memory.

Organization of this subsection
(1) Execution timing
(2) Executed details

(1) Execution timing

JavaVM executes the release process at following timings:

(2) Executed details

After the copy garbage collection or full garbage collection processing is over, an investigation is performed to check the existence of the Explicit memory blocks that JavaVM has reserved for release. If one or more corresponding Explicit memory blocks exist, those Explicit memory blocks are released. The Explicit memory blocks are released by the memory releasing API of the OS. At that time, the objects inside the released Explicit memory blocks are destroyed.

However, the objects, which are implementing the finalize method and which are not being referenced from anywhere, from among the objects in Explicit memory blocks to be released, are not destroyed. The objects are registered in the finalize queue and moved to the Java heap.

If objects in Explicit memory blocks, which are targeted for releasing, correspond to the following conditions, the operation will be different.

(a) If the objects are being referenced from outside (from a location other than the Explicit memory blocks that are targeted for releasing)

This corresponds to the case when the objects in the Explicit memory block, which are targeted for releasing, are being referenced from the objects in the following areas:

Executed details in each case are described below.

If an object is being referenced from the Java heap or the Permanent area
If an object is being referenced from an object in the Java heap or the Permanent area, the object is not destroyed.
The corresponding objects are preferentially moved to a Tenured area in the Java heap However, the objects are moved to a New area if there is no free space in the Tenured area or if the Tenured area has overflown. Even if an object is being referred from an object in the Tenured area that is already not in use, the object is targeted for moving.

If the objects are being referenced from Explicit memory blocks that are not targeted for releasing
If an object is being referenced from an object in the Explicit memory block, which is not targeted for releasing, the object is not destroyed. Even if the reference source object is in the Explicit memory block that is targeted for releasing, if the object is going to be moved in the Java heap without destroying, the object being referenced is also not deleted.

The following figure shows the operation if an object is being referenced from outside when releasing the Explicit memory block.

Figure 8-14 Operation if an object is being referenced from outside when releasing the Explicit memory block

[Figure]

The description given below takes object X as an example. Object X is an object that is included in the Explicit memory block targeted for releasing.

If object X is being referenced from an object in the Explicit memory block, which is targeted for releasing, object X is deleted.

If object X is being referenced from the Java heap, Permanent area, or from an object in an Explicit memory block that is not targeted for releasing, object X is not deleted.

Even when object X is being referenced from an object Y in an Explicit memory block that is targeted for releasing, if the reference source object Y is being referenced from an object in the Java heap, Permanent area, or from an object in an Explicit memory block that is not targeted for releasing, object X is not deleted. In such cases, both objects X and Y move to the Java heap.

(b) If the Java heap overflows when moving objects to the Java heap

This corresponds to the case when an attempt is made to move objects being referenced from outside to the Java heap and an object cannot be moved because there is no free space in the movement destination Java heap.

In such cases, full garbage collection is executed and free space is secured in the Java heap. After execution of the full garbage collection, the object is moved to the Java heap.

(c) 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 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.