A parallel, incremental and concurrent GC for servers

Abstract

Multithreaded applications with multi-gigabyte heaps running on modern servers provide new challenges for garbage collection (GC). The challenges for "server-oriented" GC include: ensuring short pause times on a multi-gigabyte heap, while minimizing throughput penalty, good scaling on multiprocessor hardware, and keeping the number of expensive multi-cycle fence instructions required by weak ordering to a minimum. We designed and implemented a fully parallel, incremental, mostly concurrent collector, which employs several novel techniques to meet these challenges. First, it combines incremental GC, to ensure short pause times, with concurrent low-priority background GC threads, to take advantage of processor idle time. Second, it employs a lowoverhead work packet mechanism to enable full parallelism among the incremental and concurrent collecting threads and ensure load balancing. Third, it reduces memory fence instructions by using batching techniques: one fence for each block of small objects allocated, one fence for each group of objects marked, and no fence at all in the write barrier. When compared to the mature well-optimized parallel stopthe-world mark-sweep collector already in the IBM JVM, our collector prototype reduces the maximum pause time from 284 ms to 101 ms, and the average pause time from 266 ms to 66 ms while losing only 10% throughput when running the SPECjbb2000 benchmark on a 256 MB heap on a 4-way 550 MHz Pentium multiprocessor.

Fine-Grained Parallel Compacting Garbage Collection through Hardware-Supported Synchronization

“…Another class of algorithms, introduced by Ossia et al [13], divides the collection work into work-packets, each containing references to a set of gray objects. Each process repeatedly removes a single packet from a shared packet pool, locally scans the objects referenced by this packet, and inserts packets with new gray references into the shared pool, thereby replacing object-level granularity by packetlevel granularity.…”

On measuring garbage collection responsiveness

“…Typically, average and maximum pause times purport to illustrate the average-and worst-case scenarios, pause time histograms and sometimes standard deviation of pause times are also shown. Examples of such publications are the following [1,13,14,16].…”

“…Several GCs perform a significant fraction of their work concurrently with the application (concurrent marking, sweeping, and so on), in addition to stop-the-world pauses [8,13,16]. A pause time distribution does not reflect the amount of work the GC did concurrently and what portion of the application's execution it affected.…”

“…Long and/or arbitrarily scheduled GC activity can disrupt the responsiveness of such applications. Hence, developers typically rely on low-latency GCs, which are now available in many commercial garbage-collected systems (for example, most current production Java virtual machines [3,13,15]), to minimize this disruption.…”

Task-pushing: a Scalable Parallel GC Marking Algorithm without Synchronization Operations

“…pause time, improve the runtime system scalability, and deliver better performance. Since Halstead introduced the first parallel GC [8], a variety of algorithms have been proposed to parallelize the GC process [10,6,7,5,4,11,14]. Today, most of the existing commercial JVMs have one or more parallel GC algorithms implemented.…”