Generational techniques have been very successful in reducing the impact of garbage collection algorithms upon the performance of programs. However, all generational algorithms occasionally promote objects that later become garbage, resulting in an accumulation of garbage in older generations. Reclaiming this tenured garbage without resorting to collecting the entire heap is a difficult problem. In this paper, we describe a mechanism that extends existing generational collection algorithms by allowing them to reclaim tenured garbage more effectively. In particular, our dynamic threatening boundary mechanism divides memory into two spaces, one for shortlived, and another for long-lived objects. Unlike previous work, our collection mechanism can dynamically adjust the boundary between these two spaces either forward or backward in time, essentially allowing data to become untenured. We describe an implementation of the dynamic threatening boundary mechanism and quantify its associated c...

Many programming languages provide automatic garbage collection to reduce the need for memory management related programming. However, traditional garbage collection techniques lead to long and unpredictable delays and are therefore not satisfactory in a number of settings, such as interactive systems, where non-disruptive behavior is of paramount importance. Advanced techniques, such as generation-based collection, alleviate the problem somewhat by concentrating collection efforts on small but hopefully gainful areas of memory, the so-called young generations. This approach reduces the need for collecting the remaining large memory area, the old generation, but in no way obviates it. Traditionally, conventional techniques have been employed for old generation collection, leading to pauses which, although less frequent, are still highly disruptive. Recently, however, Hudson & Moss have introduced a new algorithm, the Train Algorithm, for performing efficient incremental collection of o...

In many garbage collected systems, the mutator performs a write barrier for every pointer update. Using generational garbage collectors, we study in depth three code placement options for rememberedset write barriers: inlined, out-of-line, and partially inlined (fast path inlined, slow path out-of-line). The fast path determines if the collector needs to remember the pointer update. The slow path records the pointer in a list when necessary. Efficient implementations minimize the instructions on the fast path, and record few pointers (from 0.16 to 3 % of pointer stores in our benchmarks). We find the mutator performs best with a partially inlined barrier, by a modest 1.5 % on average over full inlining. We also study the compilation cost of write-barrier code placement. We find that partial inlining reduces the compilation cost by 20 to 25 % compared to full inlining. In the context of just-in-time compilation, the application is exposed to compiler activity. Regardless of the level of compiler activity, partial inlining consistently gives a total running time performance advantage over full inlining on the SPEC JVM98 benchmarks. When the compiler optimizes all application methods on demand and compiler load is highest, partial inlining improves total performance on average by 10.2%, and up to 18.5%.

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%.

We explore the ramifications of object residency assumptions and their impact on residency checking for several subroutine dispatch scenarios: procedural, static object-oriented, and dynamic (virtual) object-oriented. We obtain dynamic counts of the residency checks necessary for execution of several benchmark persistent programs under each of these scenarios. The results reveal that significant reductions in the number of residency checks can be achieved through application of residency rules derived from the dispatch scenario under which a program executes, as well as additional constraints specific to the language in which it is implemented. Keywords: residency checks, optimization, object-orientation, static/dynamic dispatch 1 Introduction Persistent programming languages view permanent storage as a stable extension of volatile memory, in which objects may be dynamically allocated, but which persists from one invocation to the next. A persistent programming language and object st...

implementations incorporate techniques that restore robustness by effectively disabling older-first collection in cases where degradation occurs, and this dissertation discusses further measures the collectors may take to avoid performance degradation. i I thank my committee members, Mitchell Wand, Rajmohan Rajaraman and Eliot Moss, and particularly my advisor, Will Clinger, for their participation, comments and help. Will Clinger also contributed in many ways over many years to Larceny, my experimental system, most obviously by writing the Twobit compiler for Scheme. The benchmarks used in this dissertation were written or modified by or in other ways contributed to by Henry Baker, Hans Boehm, Bob Boyer, Will Clinger, David Detlefs, John Ellis, Marc Feeley, Richard Gabriel, Pete Kovac, Eugene Luks, and Richard O'Keefe. The work was supported in part by NSF Grant CCR-9629801 and by the College of Computer Science at Northeastern University. The most profound thanks still go to m

We demonstrate the tradeoffs between interpreting code in compact forms (such as the bytecoded method formats used in Smalltalk and Java), and direct execution of code (as in dynamic-translation Smalltalk and just-in-time Java compilers). Experiments with the interpreted Smalltalk language show that the widely held belief that direct execution is always faster than compact interpretation is not correct. Specifically, it is untrue for memory architectures with high cache-miss penalties, where the larger volume of less frequently repeated instructions inherent in direct execution outweighs the reduction in the number of instructions executed. The experiments presented demonstrate that the space of cycle costs for different types of cache misses can be divided into regions where a particular option is faster, and that these regions differ for different cache configurations. This suggests that interpreter designers must consider memory architecture and language characteristics when decidin...

We have implemented the first copying garbage collector that permits continuous unimpeded mutator access to the original objects during copying. The garbage collector incrementally replicates all accessible objects and uses a mutation log to bring the replicas up-to-date with changes made by the mutator. An experimental implementation demonstrates that the costs of using our algorithm are small and that bounded pause times of 50 milliseconds can be readily achieved.

It is well accepted that Garbage Collection simplifies programming, promotes modularity, and reduces development effort. However it is commonly believed that these advantages do not counteract the price that has to be paid: excesive overheads, possible long pause times, and the need of modifying existing code. Even though there exist publically available garbage collectors that can be used in existing programs, they do not guarantee short pauses, and some modification of the application using them is still required. In this paper we describe a snapshot-atbeginning concurrent garbage collector algorithm and its implementation. This algorithm is less intrusive than other garbage collecting algorithms, guarantees short pauses, and can be easily implemented in stock unix like operating systems. Our results show that our collector is faster than other implementations that use user-level dirty bits, and is very competitive with explicit deallocation. These advantages are especially true on m...

We consider some issues in optimizing persistent programming languages. In particular, we show how to express optimizations of object residency checks in strongly typed persistent languages as "annotations" on pointer types. These annotations essentially extend and refine the type system of the language, and they have at least two significant uses. First, a programmer can use them to express desired residency properties to be enforced by the language implementation (compiler plus run time). Second, we can use them to separate a persistence optimizer, which adds annotations, from the remainder of the compiler, which simply obeys them. This gives rise to a nice separation of concerns in supporting high-performance persistence: the "intelligent" optimizer can be factored off from the rest of the compiler. In addition to modularity benefits, the separation allows us to explore the value of various optimizations without actually implementing them in the optimizer. Rather, we can optimize pr...