Message analysis-guided allocation and low-pause incremental garbage collection in a concurrent language

Abstract

We present a memory management scheme for a concurrent programming language where communication occurs using messagepassing with copying semantics. The runtime system is built around process-local heaps, which frees the memory manager from redundant synchronization in a multithreaded implementation and allows the memory reclamation of process-local heaps to be a private business and to often take place without garbage collection. The allocator is guided by a static analysis which speculatively allocates data possibly used as messages in a shared memory area. To respect the (soft) real-time requirements of the language, we develop a generational, incremental garbage collection scheme tailored to the characteristics of this runtime system. The collector imposes no overhead on the mutator, requires no costly barrier mechanisms, and has a relatively small space overhead. We have implemented these schemes in the context of an industrial-strength implementation of a concurrent functional language used to develop largescale, highly concurrent, embedded applications. Our measurements across a range of applications indicate that the incremental collector substantially reduces pause times, imposes only very small overhead on the total runtime, and achieves a high degree of mutator utilization.

Atom garbage collection

“…With 20,000 atoms, we will use 80 KB for a 4-byte reference count, and 40 KB for a 2-byte reference count. 6 Fourth, each ets entry needs an epoch bit. Since pointers in ets tables are word aligned, the two least address bits are unused.…”

“…Various alternative heap architectures have been proposed for Erlang/OTP, based on sharing data between processes [7,5,4,6]. For our purposes, the main difference is that several processes may share the same heap data.…”

“…Can our proposed atom garbage collector 4 Recall that in the proposed algorithm, there can be at most two tables 5 Our measurements for R9C2 indicate that 1327 modules would need roughly 512 KB, one word per referenced atom, so the actual space needed is likely to be less than this number. 6 Systems with less than 65,000 modules can make do with a 2-byte reference count. 7 Note that we cannot decrement the reference count properly if the file holding the atom information disappears.…”

High-level real-time programming in Java

“…As Sagonas and Wilhelmsson have discussed in the context of Erlang (which has a similar task model) there are tradeoffs between using a global heap in which read-only objects are shared between tasks, private heaps which are individually collected, and a hybrid of the two [22]. E-Tasks present the same implementation choices; we concentrate on the use of private heaps for the level of accountability they provide, but there is nothing about the design that precludes the other approaches.…”

Correctness-preserving derivation of concurrent garbage collection algorithms

“…Many additional incremental and concurrent algorithms have been introduced over the last 30 years [30,1,2,3,4,5,6,11,13,16,17,24,26,27,29,32,34,35,40,45], but there has been very little experimental comparison of the algorithms and no formal study of their relative merits. While there is now a well-established "bag of tricks" for concurrent collectors, each algorithm composes them differently based on the intuition and experience of the designer.…”