Fast conservative garbage collection

Shahriyar, Rifat; Blackburn, Stephen M.; McKinley, Kathryn S.

doi:10.1145/2660193.2660198

Cited by 9 publications

(5 citation statements)

References 30 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Forkscan is conservative, in that memory words which could be pointers to a memory block are automatically treated as references. We share this limitation with other automatic reclamation systems for C/C++ [4,17,50]. In theory, this assumption could prevent memory from being de-allocated, e.g.…”

Section: Limitationsmentioning

confidence: 86%

See 1 more Smart Citation

Forkscan

Alistarh

Leiserson

Matveev

et al. 2017

Proceedings of the Twelfth European Conference on Computer Systems

View full text Add to dashboard Cite

The problem of efficient concurrent memory reclamation in unmanaged languages such as C or C++ is one of the major challenges facing the parallelization of billions of lines of legacy code. Garbage collectors for C/C++ can be inefficient; thus, programmers are often forced to use finelycrafted concurrent memory reclamation techniques. These techniques can provide good performance, but require considerable programming effort to deploy, and have strict requirements, allowing the programmer very little room for error. In this work, we present Forkscan, a new conservative concurrent memory reclamation scheme which is fully automatic and surprisingly scalable. Forkscan's semantics place it between automatic garbage collectors (it requires the programmer to explicitly retire nodes before they can be reclaimed), and concurrent memory reclamation techniques (as it does not assume that nodes are completely unlinked from the data structure for correctness). Forkscan's implementation exploits these new semantics for efficiency: we leverage parallelism and optimized implementations of signaling and copy-on-write in modern operating systems to efficiently obtain and process consistent snapshots of memory that can be scanned concurrently with the normal program operation. Empirical evaluation on a range of classical concurrent data structure microbenchmarks shows that Forkscan can preserve the scalability of the original code, while main

show abstract

Section: Limitationsmentioning

confidence: 86%

“…In general, this approach can suffer from high overheads due to the page protection mechanism [20]. The garbage collection work probably closest to ours is that of Shahriyar et al [51], which performs conservative reference counting and cycle detection, with write barriers on pointer mutations.…”

Section: Related Workmentioning

confidence: 99%

Forkscan

Alistarh

Leiserson

Matveev

et al. 2017

Proceedings of the Twelfth European Conference on Computer Systems

View full text Add to dashboard Cite

show abstract

“…Our GC implements an Immix allocator which is mainly a bump pointer allocator, while BDW uses a free list allocator. Immix outperforms freelist allocators by 16% in large benchmarks [17]; we expect the performance advantage is even bigger in micro benchmarks that allocate in a tight loop. We ran our alloc micro benchmark for BDW, and we find that the performance difference between our allocator and the BDW allocator is similar, confirming our belief.…”

Section: Gcbenchmentioning

confidence: 86%

Rust as a language for high performance GC implementation

et al. 2016

Self Cite

View full text Add to dashboard Cite

High performance garbage collectors build upon performancecritical low-level code, typically exhibit multiple levels of concurrency, and are prone to subtle bugs. Implementing, debugging and maintaining such collectors can therefore be extremely challenging. The choice of implementation language is a crucial consideration when building a collector. Typically, the drive for performance and the need for efficient support of low-level memory operations leads to the use of low-level languages like C or C++, which offer little by way of safety and software engineering benefits. This risks undermining the robustness and flexibility of the collector design.Rust's ownership model, lifetime specification, and reference borrowing deliver safety guarantees through a powerful static checker with little runtime overhead. These features make Rust a compelling candidate for a collector implementation language, but they come with restrictions that threaten expressiveness and efficiency.We describe our experience implementing an Immix garbage collector in Rust and C. We discuss the benefits of Rust, the obstacles encountered, and how we overcame them. We show that our Immix implementation has almost identical performance on micro benchmarks, compared to its implementation in C, and outperforms the popular BDW collector on the gcbench micro benchmark. We find that Rust's safety features do not create significant barriers to implementing a high performance collector. Though memory managers are usually considered low-level, our high performance implementation relies on very little unsafe code, with the vast majority of the implementation benefiting from Rust's safety. We see our experience as a compelling proof-of-concept of Rust as an implementation language for high performance garbage collection. } 132 } 133 134 // functions are inlined so we omit 135 // parameters/arguments 136 #[inline(always)] 137 #[cfg(feature = "parallel-gc")] 138 pub fn steal_trace_object(...) { 139 let addr = obj.to_address();

show abstract

“…There are two groups of techniques: deferral and coalescing. In deferral [12,15,18,[37][38][39][40], the mutation phase does not perform RC operations for local pointer variables stored in the stack or registers. Then, the collection phase scans the stack and registers, and determines the objects that have a reference count equal to zero, and therefore can be reclaimed.…”

Section: Rc Optimizationmentioning

confidence: 99%

Biased reference counting

Choi

Shull

Torrellas

2018

Proceedings of the 27th International Conference on Parallel Architectures and Compilation Techniques

View full text Add to dashboard Cite

Reference counting (RC) is one of the two fundamental approaches to garbage collection. It has the desirable characteristics of low memory overhead and short pause times, which are key in today's interactive mobile platforms. However, RC has a higher execution time overhead than its counterpart, tracing garbage collection. The reason is that RC implementations maintain per-object counters, which must be continually updated. In particular, the execution time overhead is high in environments where low memory overhead is critical and, therefore, non-deferred RC is used. This is because the counter updates need to be performed atomically. To address this problem, this paper proposes a novel algorithm called Biased Reference Counting (BRC), which significantly improves the performance of non-deferred RC. BRC is based on the observation that most objects are only accessed by a single thread, which allows most RC operations to be performed non-atomically. BRC leverages this by biasing each object towards a specific thread, and keeping two counters for each object-one updated by the owner thread and another updated by the other threads. This allows the owner thread to perform RC operations non-atomically, while the other threads update the second counter atomically. We implement BRC in the Swift programming language runtime, and evaluate it with client and server programs. We find that BRC makes each RC operation more than twice faster in the common case. As a result, BRC reduces the average execution time of client programs by 22.5%, and boosts the average throughput of server programs by 7.3%. CCS CONCEPTS • Software and its engineering → Garbage collection; Software performance; Runtime environments;

show abstract

Fast conservative garbage collection

Cited by 9 publications

References 30 publications

Forkscan

Forkscan

Rust as a language for high performance GC implementation

Biased reference counting

Contact Info

Product

Resources

About