How Java garbage collection works

In C + +, allocating objects on the heap is more expensive than allocating objects on the stack. The program needs to find the appropriate memory block and return the memory address. In Java, however, the garbage collector significantly increases the speed at which objects are allocated on the heap. It may sound strange, but that's how the Java garbage collector works. And this means that the allocation of objects on the heap in Java is almost as fast as other languages allocating objects on the stack.

For example, the heap in C + + is like a yard, with each object occupying its own territory. In some JVMs, Java's heap is more like a conveyor belt, and each time an object is allocated, the Carousel moves forward (without looking for the right memory space).

Understanding how garbage collection works in other systems is helpful in understanding Java garbage collection. A simple but inefficient garbage collection mechanism is a reference count. In this mechanism, each object has an application count value, each time a reference is directed to an object, and the reference count value of the object is added one. Each time a reference leaves the scope or is set to NULL, the object's reference count value is reduced by one. Therefore, managing reference counts is a small but persistent cost in the program life cycle. The garbage collector iterates over the object when it finds that the reference count value of the object is 0, which means that the program can no longer manipulate the object, and the object will be recycled. One drawback is that several objects have circular references and are not referenced by other objects. These objects need to be reclaimed, but the reference count values for these objects are not 0. Checking for circular references requires the garbage collector to do extra work. Reference counting is often used to explain how garbage collection works, but it is not used by any JVM implementations.

In some fast garbage collection mechanisms, garbage collection is not based on reference counting. In fact, garbage collection is based on the fact that any active object can be found through a chained reference through a stack or a static object. This chained reference can go through a number of objects. So if you start with a stack or a static object and iterate through all the references, all the active objects will be found. For each object found, continue to look for all the objects it references until you can no longer discover new objects. It is important to note that circular reference issues have been resolved and they are not discovered and therefore automatically recycled.

The JVM uses an adaptive garbage collection mechanism, which is related to the variant it is currently using. One variant is stop-copy (stop and copy). This means that the program is first stopped (there is no background recycling mechanism), and then each active object is copied from the original heap into the new heap, and all objects that need to be reclaimed are discarded in the original heap. Because all active objects are copied into the new heap, they are reassigned, tightly connected, making the new heap less space, and allowing new objects to be allocated directly behind the heap space.

When an object is moved from one place to another, all references to that object need to be changed. A reference from a stack or a static object can be changed directly, and a reference to the heap object is subsequently changed. In fact, after the object is copied, a table is created, and the index of the old address to the new address is established in the table. Then iterate through the heap objects and modify the addresses they are referencing.

There are two issues that result in a stop-copy (stop and copy) mechanism that is less efficient. The first one is two heap, and twice times the actual memory needs to be managed. Some JVMs copy only one piece of memory at a time by blocking the heap.

The second problem comes from the replication process itself. When the program is stable, there will be little or no rubbish to produce. Even so, the stop-copy (stop and copy) mechanism still replicates all memory from one place to another, largely reducing the performance of the program.

To solve this problem, some JVMs switch to another mechanism when they detect little or no garbage generation (this shows the adaptability of the JVM garbage collection mechanism). This mechanism is called Token-Exchange (MARK-AND-SWEEP). This mechanism has been used in the early days of Sun's JVM. For the general case, the mark-swap mechanism is slow, but the mechanism is faster when the resulting garbage is little or no more.

The stop-copy mechanism uses the same logic: starting with a stack or a static object, traversing all references to discover the active object. Whenever an active object is found, a tag is set for the object. When the traversal is complete, all active objects are marked for completion. All objects are traversed and all objects that are not marked are recycled. No replication occurred during this process. So if the garbage collector needs to shrink the heap, it needs to change the position of the object to fill the space after the recycle.

How Java garbage collection works