List processing in real time on a serial computer

Abstract

A real-time list processing system is one in which the time required by each elementary list operation (CONS, CAR, CDR, RPLACA, RPLACD , EQ, and ATOM in LISP) is bounded by a (small) constant. Classical list processing systems such as LISP do not have this property because a call to CONS may invoke the garbage collector which requires time proportional to the number of accessible cells to finish. The space requirement of a classical LISP system with N accessible cells under equilibrium conditions is (1.5+11)N or (I+p1)N, depending upon whether a stack is required for the garbage collector, where />0 is typically les than 2.A list processing system is presented which: 1) is real-time--i.e. T(CONS) is bounded by a constant independent of the number of cells in use; 2) requires space (2+21p)N, i.e. not more than twice that of a classical system; 3) runs on a serial computer without a time-sharing clock; 4) handles directed cycles in the data structures; 5) is fast--the average time for each operation is about the same as with normal garbage collection; 6) compacts--minimizes the working set; 7) keeps the free pool in one contiguous block--objects of nonuniform size pose no problem; 8) uses one phase incremental collection--no separate mark, sweep, relocate phases; 9) requires no garbage collector stack; 10) requires no "mark bits", per se; 11) is simple-suitable for microcoded implementation. Extensions of the system to handle a user program stack, compact list representation ("CI)R-co ling"), arrays of non-uniform size, and hash linking are discussed. CDR-coding is shown to reduce memory requirements for N LISIP cells to -s(I+)N. Our system is also compared with another approach to the real-time storage management problem, reference counting, and reference counting is shown to be neither competitive with our system when speed of allocation is critical, nor compatible, in the sense that a ýystem with both forms of garbage collection is worse than our pure one.

Scheduling real-time garbage collection on uniprocessors

“…In other copying GCs, the need for restarts of copies is sometimes avoided by putting more responsibility on the mutator. In Baker [1978], a software barrier is proposed that redirects writes to the correct location, even if the object is being currently copied. The software solution however has a significant overhead [Schmidt and Nilsen 1994].…”

Hardware Support for Embedded Java

“…Here the focus is on hardware support for garbage collection Nielsen and Schmidt [37] propose hardware support, the object-space manager (OSM), for real-time garbage collector on a standard RISC processor. The concurrent garbage collector is based on [5], but the concurrency is of finer grain than the original Baker algorithm as it allows the mutator to continue during the object copy. The OSM redirects field access to the correct location for an object that is currently being copied.…”

“…In that case, the GC unit steals memory bandwidth from the application thread. The GC hardware uses an implementation of Baker's read-barrier [5] for the incremental copying algorithm. The cost of the read-barrier is between 5 and 50 clock cycles.…”

Component Composition for Embedded Systems Using Semantic Aspect-Oriented Programming

“…Real-time garbage collection [27,23] provides an alternative to region-based memory management for real-time programs. It has the advantage that programmers do not have to explicitly deal with memory management.…”