Skip to content

zz note: Garbage Collection

David Jeske edited this page May 11, 2017 · 12 revisions

The current Irken garbage collector is a very simple Cheney two-space copying collector. It consists of 153 lines of C.

A simple optimization is to allocate large data-objects with no pointers, such as large buffers or vectors, outside the GC heap. (See CLR large object heap)

The next step is a better collector...

Beltway

One option is a generational collector known as Beltway. It's a flexible model for a non-concurrent non-parallel generational garbage collector. One advantage of Beltway is its relatively straightforward implementation. One disadvantage of Beltway is that as the tenured generation grows, like most generational collectors, it degenerates into the same worst-case as a single-generation collector, with long worst-case pause times, and half of memory reserved for copy-space.

Dijkstra Concurrent Collector

Another option is to use a concurrent collector. Google Go has gone this route and is having great success -- with pause times under 10ms even on 20GB heaps. They are using a fairly simple early concurrent design, from 1978. This effectively gives up GC throughput for lower latency, which is a reasonable choice to make in a world of huge heaps and lots of cores. One of the biggest drawbacks of this approach is that it also requires at least 100% memory overhead, for a huge copy-to space.

C4 : The Continuously Concurrent Compacting Collector

The state of the art in pauseless concurrent collectors is C4.

C4 is a collector available in the commercial Azul Zing JVM. One advantage of C4 is that it is truely pauseless, meaning it has zero heap-size proportional stop-the-world. It also needs only one page (typically 4k) of copy-space overhead, regardless of heap-size, because once a page is relocated, it's physical backing store is relocated; while it's virtual address space is guarded to trap and fix forwarding references. One disadvantage of C4, is that it's implementation is more complex, and it relies on virtual-memory guard-pages for a hard-ware assisted optimistic read-barrier, in order to handle concurrency and forwarding.

Other Notes