Scalable concurrent and parallel mark

Abstract

Parallel marking algorithms use multiple threads to walk through the object heap graph and mark each reachable object as live. Parallel marker threads mark an object "live" by atomically setting a bit in a mark-bitmap or a bit in the object header. Most of these parallel algorithms strive to improve the marking throughput by using work-stealing algorithms for load-balancing and to ensure that all participating threads are kept busy. A purely "processorcentric" load-balancing approach in conjunction with a need to atomically set the mark bit, results in significant contention during parallel marking. This limits the scalability and throughput of parallel marking algorithms.We describe a new non-blocking and lock-free, work-sharing algorithm, the primary goal being to reduce contention during atomic updates of the mark-bitmap by parallel task-threads. Our worksharing mechanism uses the address of a word in the mark-bitmap as the key to stripe work among parallel task-threads, with only a subset of the task-threads working on each stripe. This filters out most of the contention during parallel marking with ∼20% improvements in performance.In case of concurrent and on-the-fly collector algorithms, mutator threads also generate marking-work for the marking taskthreads. In these schemes, mutator threads are also provided with thread-local marking stacks where they collect references to potentially "gray" objects, i.e., objects that haven't been "markedthrough" by the collector. We note that since this work is generated by mutators when they reference these objects, there is a high likelihood that these objects continue to be present in the processor cache. We describe and evaluate a scheme to distribute mutator generated marking work among the collector's task-threads that is cognizant of the processor and cache topology. We prototype both our algorithms within the C4 [28] collector that ships as part of an industrial strength JVM for the Linux-X86 platform.

Understanding and improving JVM GC work stealing at the data center scale

“…Work-sharing [10] uses the address of a word in the markbitmap as the key to stripe work among parallel threads. This reduces contention during the update of the mark-bit-map.…”

Big Data Challenges: A Program Optimization Perspective

“…There exists a large body of work on garbage collection (GC) (a comprehensive bibliography on garbage collection is available at [88]). Recently, several GC techniques, addressing concurrency and scalability, have been proposed [89], [90], [91]. In a similar vein, a multitude of techniques have been proposed for automatic adaptive heap sizing [92], [93].…”

Mark without much Sweep Algorithm for Garbage Collection

“…Its numerous function calls produce overhead and may cause system stack overflow. Explicit marking-stack is often used since its overflow is handled much easier and it avoids the function calls [1,4,7,8].…”