Database Reference
In-Depth Information
Garbage Collection
In Java systems, the developer does not need to explicitly configure memory allocation and
deallocation. Instead the system will automatically allocate the memory for the Java objects,
and whenever the objects are terminated, the background process called the garbage collect-
or (GC) will remove or destroy the memory area so that space is freed up for allocation to a
new Java object. This way, the programmer does not have to worry about memory alloca-
tion and Java programming is more efficient and easy to use. Since GC is an automated pro-
cess, the number of memory leaks caused by developer errors is also minimized. The fol-
lowing section will cover details of the GC process, types, and its effects on system per-
formance. In order to explain the GC process in detail, different scenarios of memory alloca-
tion and deallocation are discussed so that the reader can get a good conceptual understand-
ing of the GC process and how it can lead to situations such as Java system crashes in situ-
ations where either the memory is incorrectly configured or there is no adequate amount of
physical memory available to the system.
Memory Areas in Garbage Collection
The two major memory areas that come into play during the GC process are the young gen-
eration memory area and the tenured (old) generation memory area. The sum of the young
generation and tenured (old) generation memory areas is the maximum configured heap
size.
Figure 23-2
shows the different memory areas in the JVM and how the GC process
works internally. The young generation area is further divided into the “Eden” and two “sur-
vivor spaces.” New Java objects are allocated memory space in the Eden memory area of
the young generation memory area. The survivor spaces are configured approximately to be
one-eighth the size of the young generation area. In
Figure 23-2
Java objects A, B, and C
are new and are, therefore, allocated memory space in the Eden area of the young generation
memory area. Survivor spaces 1 and 2 have Java objects that have been in use for sometime
but are not still alive and are not yet ready to be moved to the tenured generation memory
area.
