Database Reference
In-Depth Information
F
IGURE
23-3
Minor garbage collection process initialization scenario
Please note that the minor GC process does not scan or clear any objects in the tenured
memory area or the permanent memory area. Java objects that are still alive in the survivor
memory space can be moved to the tenured memory area based on several criteria. It is also
possible that the Java objects in the survivor spaces can be moved back and forth between
the two spaces.
In
Figure 23-4
a complete minor garbage collection scenario is discussed. A new Java
object D needs memory to be allocated as per application usage. Since the Eden area already
has three Java objects, A, B, and C, there is no additional memory for the new Java object D
in the Eden memory area, and this results a memory allocation failure, which triggers the
minor garbage collection process. This process scans the entire young generation memory
area and finds that Java object A is not alive and is no longer needed. The minor GC process
will destroy the memory area of Java object A, and this can now be allocated to the new
Java object D. This is a very simplistic description of the minor GC process. In real-life
scenarios far more objects will need memory space in the Eden memory area and far more
objects will not live and their memory areas will be destroyed by the minor GC process. The
memory allocation model assumes the “weak generational hypothesis,” which states that a
significant percentage of Java objects live for a very short period. Once usage is complete,
the memory area is destroyed by the minor GC process and is freed up for the new Java ob-
jects.
