7.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
JavaVM executes the release process at following timings:
-
When copy GC occurs
-
When Full GC occurs
(2) Executed details
After copy GC or Full GC processing ends, the Java VM checks for any Explicit memory blocks for which no reservation for release is made. 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:
-
Java heap
-
Metaspace area
-
Explicit memory block which is not targeted for releasing
Executed details in each case are described below.
- If an object is being referenced from the Java heap or the Metaspace area
-
If an object is being referenced from an object in the Java heap or the Metaspace 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]](GRAPHICS/ZU081100.GIF)
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, Metaspace 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, Metaspace 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 this case, Full GC is performed and free space is secured in the Java heap. The objects move to the Java heap after Full GC ends.
(c) If sufficient free space cannot be secured by Full GC
This corresponds to the case where the Java heap ran out of free space and the free space required for moving Java objects cannot be secured even by performing Full GC. 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.