Why a Garbage Collector Can Freeze an App
A program does not use every object it has created forever. A garbage collector finds which objects are still reachable—meaning the program can get to them through active references—and reclaims memory occupied by the rest. To make that decision safely, some collectors temporarily stop the program’s threads from changing those references.
The collector begins with roots: references held in places such as thread stacks and global variables. It follows links from those roots through the heap, the area where many program objects live. Objects it can reach are kept; objects it cannot reach are candidates for reclamation. Without a pause, a running thread might change a reference halfway through this scan, making the collector’s picture inconsistent.
The Cost of a Cleaner Heap
During a stop-the-world pause, the application cannot do useful work. A collector may also move surviving objects to reduce fragmentation, the scattered gaps that can make it harder to find a large free block. Moving objects requires adjusting references so the program can still find them.
The interruption is especially noticeable in software that must respond promptly, such as a game or a real-time service. A brief pause can become a visible hitch or a delayed request, even though the reclaimed memory helps the program continue running.
Other collectors do more work concurrently with the application, reducing pauses but adding complexity and using processor time while the program runs. The tradeoff is not simply “collect or do not collect”: it is how to keep memory accurate and available while limiting the moments when the program must wait.
