Explanation of Azul's “pauseless” garbage collector

Question

I\'ve just read this:

http://www.artima.com/lejava/articles/azul_pauseless_gc.html

Although I\'ve some experience with compilers, I\'ve done nothing related

Answer 1

why garbage collectors have that pause in general?

GCs work by tracing reachable heap blocks starting from a set of global roots (global variables, thread stacks and CPU registers). GCs lie on a sliding scale from snapshot to on-the-fly. Snapshot GCs work from a snapshot of the global roots and heap topology. On-the-fly GCs incrementally update their interpretation of the heap as the mutators run.

Wholly snapshot GCs attain high throughput because the collector runs almost entirely independently of the mutators but have high latency because taking a snapshot incurs a pause. Wholly on-the-fly GCs attain low latency because everything is done incrementally but low throughput because of the fine-grained communication between the mutators and GC.

In practice, all GCs lie somewhere between these two extremes. VCGC is primarily a snapshot GC but it uses a write barrier to keep the collector apprised of changes to the heap topology. Staccato was the world's first parallel and concurrent and real-time GC but it still batches up some operations in order to retain the efficiency of stack allocation.

why Azul's gc doesn't have that problem?

They do still have this problem but they lessened it by implementing a read barrier in hardware. Read barriers had been proposed before but software read barriers degrade throughput too much because pointer reads are much more common than writes.