We describe a concurrent, atomic garbage collection algorithm for transaction-based languages, a class of languages intended to support reliable distributed systems. A garbage collection algorithm for reliable distributed systems must be atomic: a crash during a garbage collection should result in no loss of data. A concurrent collector allows programs to continue operating as their heaps are collected, minimizing delays imposed by collection. A concurrent collector can be used in reliable distributed systems that must service interactive requests. We introduce concurrency into an atomic collector by breaking collection into a series of garbage collection segments, which are similar to transactions, but satisfy weaker properties than are required by transaction semantics. These weaker properties allow better performance. Thus, our collection algorithm enhances the reliability of programs written in transaction-based languages, without necessarily imposing severe performance penalties. ...

With concurrent and garbage collected languages like Java and C# becoming popular, the need for a suitable non-intrusive, efficient, and concurrent multiprocessor garbage collector has become acute. We propose a novel mark and sweep on-the-fly algorithm based on the sliding views mechanism of Levanoni and Petrank. We have implemented our collector on the Jikes Java Virtual Machine running on a Netfinity multiprocessor and compared it to the concurrent algorithm and to the stop-the-world collector supplied with Jikes JVM. The maximum pause time that we measured with our benchmarks over all runs was 2ms. In all runs, the pause times were smaller than those of the stop-the-world collector by two orders of magnitude and they were also always shorter than the pauses of the Jikes concurrent collector. Throughput measurements of the new garbage collector show that it outperforms the Jikes concurrent collector by up to 60%. As expected, the stop-the-world does better than the on-the-fly collectors with results showing about 10% difference. On top of being

model for garbage collection.

Topaz, the experimental computing environment built and used at SRC, is implemented in the Modula-2+ programming language, which provides garbage collection. Garbage collection simplifies the construction of complex systems, and is tied to a number of other Topaz and Modula-2+ features, such as runtime polymorphism, language safety, information-hiding, object cleanup, persistent objects, and network objects. Although there are costs to using garbage collection, these are avoided or tolerated in Topaz. For example, because Topaz must avoid noticeable interruption of service due to garbage collection, it uses a concurrent garbage collector. Measurements show that the use of the REF heap in Topaz is similar in many ways to the use of heaps in Lisp-like environments, but different in others. For example, in typical large Topaz programs, the REF heap contains millions of bytes, with tens of thousands of objects from among hundreds of staticallydeclared types; objects of only a few types pre...

An on-the-fly garbage collector does not stop the program threads to perform the collection. Instead, the collector executes in a separate thread (or process) in parallel to the program. On-the-fly collectors are useful for multithreaded applications running on multiprocessor servers, where it is important to fully utilize all processors and provide even response time, especially for systems for which stopping the threads is a costly operation. In this work, we report on the incorporation of generations into an on-the-fly garbage collector. The incorporation is non-trivial since an on-the-y collector avoids explicit synchronization with the program threads. To the best of our knowledge this incorporation has not been tried before. We have implemented the collector for a prototype Java Virtual Machine on AIX, and measured its performance on a 4-way multiprocessor. As for other generational collectors, an on-the-fly generational collector has the potential for reducing the overall running time and working set of an application by concentrating collection efforts on the young objects. However, in contrast to other generational collectors, on-the-fly collectors do not move the objects; thus, there is no segregation between the old and the young objects. Furthermore, on-the-fly collectors do not stop the threads, so there is no extra benefit for the short pauses obtained by generational collection. Nevertheless, comparing our on-the-fly collector with and without generations, it turns out that the generational collector performs better for most applications. The best reduction in overall running time for the benchmarks we measured was 25%. However, there were some benchmarks for which it had no e ect and one for which the overall running time increased by 4%.

Tracing and reference counting are uniformly viewed as being fundamentally different approaches to garbage collection that possess very distinct performance properties. We have implemented highperformance collectors of both types, and in the process observed that the more we optimized them, the more similarly they behaved — that they seem to share some deep structure. We present a formulation of the two algorithms that shows that they are in fact duals of each other. Intuitively, the difference is that tracing operates on live objects, or “matter”, while reference counting operates on dead objects, or “anti-matter”. For every operation performed by the tracing collector, there is a precisely corresponding anti-operation performed by the reference counting collector. Using this framework, we show that all high-performance collectors (for example, deferred reference counting and generational collection) are in fact hybrids of tracing and reference counting. We develop a uniform cost-model for the collectors to quantify the trade-offs that result from choosing different hybridizations of tracing and reference counting. This allows the correct scheme to be selected based on system performance requirements and the expected properties of the target application.

We study an incorporation of generations into a modern reference counting collector. We start with the two on-the-y collectors suggested by Levanoni and Petrank: a reference counting collector and a tracing (mark and sweep) collector. We then propose three designs for combining them so that the reference counting collector collects the young generation or the old generation or both. Our designs maintain the good properties of the Levanoni-Petrank collector. In particular, it is adequate for multithreaded environment and a multiprocessor platform, and it has an ecient write barrier with no synchronization operations. To the best of our knowledge, the use of generations with reference counting has not been tried before.

Topaz is an experimental distributed computing environment programmed in Modula-2+, which supports garbage collection. Topaz has been in daily use by about 50 researchers at SRC since 1986. The Modula-2+ garbage collector is concurrent; it combines reference-counting and mark-and-sweep collection. The principal challenges are to reduce the costs of the language primitives, and to reduce the time spent in the collector. (This position paper contains material from references [4] and [5].) 1 Background The Topaz experience illustrates how it is possible to extend a systems implementation language with garbage collection, and successfully use it to build a large software environment. Modula-2+ [9] is the main systems implementation language at Digital Equipment Corporation's Systems Research Center (SRC). Modula-2+ is an extension of Modula2 [11]; it adds language support for concurrency, exceptions, and garbage collection. In particular, Modula-2+ adds the REF type constructor, which gen...

Multithreaded applications with multi-gigabyte heaps running on modern servers provide new challenges for garbage collection (GC). The challenges for “server-oriented ” GC include: ensuring short pause times on a multi-gigabyte heap while minimizing throughput penalty, good scaling on multiprocessor hardware, and keeping the number of expensive multi-cycle fence instructions required by weak ordering to a minimum. We designed and implemented a collector facing these demands building on the mostly concurrent garbage collector proposed by Boehm et al. Our collector incorporates new ideas into the original collector. We make it parallel and incremental; we employ concurrent low-priority background GC threads to take advantage of processor idle time; we propose novel algorithmic improvements to the basic mostly concurrent algorithm improving its efficiency and shortening its pause times; and finally, we use advanced techniques, such as a low-overhead work packet mechanism to enable full parallelism among the incremental and concurrent collecting threads and ensure load balancing. We compared the new collector to the mature, well-optimized, parallel, stop-the-world marksweep collector already in the IBM JVM. When allowed to run aggressively, using 72 % of the CPU utilization during a short concurrent phase, our collector prototype reduces the maximum pause time from 161ms to 46ms while only losing 11.5 % throughput when running the SPECjbb2000 benchmark on a 600 MB heap on an 8-way PowerPC 1.1 GHz processors. When the collector is limited to a non-intrusive operation using only 29 % of the CPU utilization, the maximum pause time obtained is 79ms and the loss in throughput is 15.4%.

We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and resident persistent objects, and to compute the reachability closure necessary for stabilization of the persistent heap. It has been implemented in our prototype of reachability-based persistence for Modula-3, yielding performance competitive with that of comparable, but non-orthogonal, persistent variants of C++. Experimental results, using the OO7 object database benchmarks, reveal that the mostly-copying approach offers a straightforward path to efficient orthogonal persistence in these uncooperative environments. The results also characterize the performance of persistence implementations based on virtual memory protection primitives. 1 Introduction Incorporating orthogonal persistence [11] ...