C4

Abstract

C4, the Continuously Concurrent Compacting Collector, an updated generational form of the Pauseless GC Algorithm [7], is introduced and described, along with details of its implementation on modern X86 hardware. It uses a read barrier to support concurrent compaction, concurrent remapping, and concurrent incremental update tracing. C4 differentiates itself from other generational garbage collectors by supporting simultaneous-generational concurrency: the different generations are collected using concurrent (non stop-the-world) mechanisms that can be simultaneously and independently active. C4 is able to continuously perform concurrent young generation collections, even during long periods of concurrent full heap collection, allowing C4 to sustain high allocation rates and maintain the efficiency typical to generational collectors, without sacrificing response times or reverting to stop-the-world operation. Azul systems has been shipping a commercial implementation of the Pauseless GC mechanism, since 2005. Three successive generations of Azul's Vega series systems relied on custom multi-core processors and a custom OS kernel to deliver both the scale and features needed to support Pauseless GC. In 2010, Azul released its first software-only commercial implementation of C4 for modern commodity X86 hardware, using Linux kernel enhancements to support the required feature set. We discuss implementation details of C4 on X86, including the Linux virtual and physical memory management enhancements that were used to support the high rate of virtual memory operations required for sustained pauseless operation. We discuss updates to the collector's management of the heap for efficient generational collection and provide throughput and pause time data while running sustained workloads.

Retrofitting parallelism onto OCaml

“…Although our stop-the-world minor collector scaled up admirably to at least 24 cores, synchronisation costs will inevitably increase as the number of cores do. Adding a read barrier (as used by the concurrent minor collector) opens up the GC design space considerably; for example to add a pauseless algorithm [Click et al 2005] such as the ones used in modern Java GCs like Azul, ZGC [Tene et al 2011] or Shenandoah [Flood et al 2016]. Our results for the concurrent minor collector show that the read barrier has less overhead in OCaml code than initially expected, and would be a reasonable solution in many-core machines.…”

RadixVM

“…As a result, application developers often work around the virtual memory system to minimize or circumvent this bottleneck. Multithreaded memory allocators provide a rich set of workaround examples: they allocate memory in large chunks from the operating system in each thread [21], batch many munmaps [13], don't return memory at all [15], or provide a loadable kernel module that implements custom VM operations for the allocator [26]. Some workarounds have deep structural implications, such as implementing an application as communicating single-threaded processes instead of as a single multi-threaded process [6].…”