Java vs Go: A Comparative Analysis of Garbage Collection Algorithms

Modern high-level programming languages manage memory through either manual or automatic approaches. Languages like C and C++ require manual memory management, while PHP, Java, and Go use automatic memory management systems with allocators and garbage collectors (GC). This article compares Java and Go's garbage collection algorithms.

1. GC Regions

Java's runtime memory areas include the heap and method area as the primary regions managed by GC. The program counter, virtual machine stack, and native method stack are thread-dependent and have known memory requirements at compile time. In contrast, Go divides memory into heap and stack regions, with the heap being the main GC target.

2. GC Trigger Conditions

Java triggers GC when the application is idle or when heap memory is insufficient. Specific triggers include: Minor GC when Eden space is insufficient, Young GC when objects reach certain age, Old GC when old generation space is insufficient, and Full GC via System.gc() calls. Go triggers GC through runtime.mallocgc when allocating memory, runtime.GC for manual triggers, and runtime.forcegchelper for background timed checks.

3. Collection Algorithms

Java uses generational collection: mark-copy for young generation (where most objects die young) and mark-sweep or mark-compact for old generation (where objects survive longer). Go uses mark-sweep algorithm exclusively.

4. Memory Fragmentation Handling

Java handles fragmentation through space compression and generational collection. The G1 collector supports object movement to reduce fragmentation, and region-based design makes it easier to return free memory to the OS.

Go's approach differs significantly: (1) Span memory pool design reduces fragmentation by returning unused spans from mcache to mcentral to mheap to OS. (2) TCMalloc allocation optimizes tiny objects (less than 16B) by pooling them in 16B objects, improving space utilization from 45.83% to 68.75%. (3) Structs can be allocated on the stack through compile-time escape analysis, reducing GC pressure.

5. GC Roots Selection

Java selects GC roots from: objects in virtual machine stack local variable tables, native method stack references, static field references in method area, constant references in method area, JVM internal references, and synchronized lock-held objects. Go's GC roots are simpler: global variables and G Stack reference pointers.

6. Write Barriers

To solve the dangling pointer problem in concurrent tri-color analysis, Java uses Dijkstra insert write barrier (CMS) and Yuasa delete write barrier (G1, Shenandoah). Go combines both into a hybrid write barrier since v1.8, scanning all stack objects as black, marking new stack objects as black, marking deleted objects as gray, and marking added objects as gray. The hybrid write barrier applies only to heap, not stack, to maintain runtime efficiency.

Summary

After multiple generations of development, Java's GC mechanism is relatively mature with young/old generation division. Objects typically allocate in young generation, with surviving objects moved to old generation. Go uses a non-generational, concurrent, tri-color mark-sweep garbage collector whose advantages are best understood alongside its TCMalloc memory allocation strategy, where small object allocation has its own memory pool and all fragments can be perfectly reused.