Concurrent garbage collection on stock hardware

Abstract

I. I n t r o d u c t i o nThis paper describes the design and implementation of a memory management system for Pegasus. Pegasus is a system that supports the implementation of programming environments and Applications are written in PML and are usually built on the services of the core library. One of the important features of Pegasus is that it supports multiple processes (or threads) in a shared address space.PML is derived from ML [M~srsS]~aCQsS]. It is a strongly typed, polymorphic language, with functions as "first class" values, and multiple processes which communicate via typed channels.Because it is a high-level language, PML requires extensive run-time support. One of the most crucial aspects of this support is the memory management system. Since it is inherently a heapbased language, the cost of memory management has a strong effect on the efficiency of any PML implementation. For example, because of the polymorphic type system of PML, functions always take exactly one argument; a function with multiple parameters takes a tuple object as its single argument. This means that most function applications involve memory allocation. Thus the speed of memory allocation and reclamation has a significant effect on the speed of PML programs.Furthermore, because Pegasus is used for interactive applications, it is important that memory operations complete in a bounded amount of time (i.e., that they are real-time).

On scheduling garbage collector in dynamic real-time systems with statistical timing assurances

“…The idea of running the collector as a separate, concurrent thread has its roots in many work-based approaches-e.g., Appel et al (1988); Nettles and O'Toole (1993); North and Reppy (1987). However, one of the first efforts where this was done for real-time GC with assurances on mutator timing behavior is Henriksson's work (Henriksson 1998).…”

Scheduling of hard real-time garbage collection

“…A Brooks-style [12] forwarding directs the access to the object either into tospace or fromspace. The forwarding pointer is kept in a separate handle area as proposed in [21]. The separate handle area reduces the space overheads as only one pointer is needed for both object copies.…”

Nonblocking real-time garbage collection

“…On a standard uniprocessor preemption points are common practice for short critical section to synchronized mutator and GC threads. The forwarding pointer is kept in a separate handle area, as proposed by North and Reppy [1987]. The separate handle area reduces the space overheads, because only one pointer is needed for both object copies.…”