This paper examines the use of generational garbage collection techniques for a lazy implementation of a non-strict functional language. Detailed measurements which demonstrate that a generational garbage collector can substantially out-perform non-generational collectors, despite the frequency of write operations in the underlying implementation, are presented. Our measurements are taken from a state-of-the-art compiled implementation for Haskell, running substantial benchmark programs. We make measurements of dynamic properties (such as object lifetimes) which affect generational collectors, study their interaction with a simple generational scheme, make direct performance comparisons with simpler collectors, and quantify the interaction with a paging system. The generational collector is demonstrably superior. At least for our benchmarks, it reduces the net storage management overhead, and it allows larger programs to be run on a given machine before thrashing ensues. 1 Introducti...

model for garbage collection.

A memory manager that does not move objects may suffer from memory fragmentation. Compaction is an efficient, and sometimes inevitable, mechanism for reducing fragmentation. A Mark-Sweep garbage collector must occasionally execute a compaction, usually while the application is suspended. Compaction during pause time can have detrimental effects for interactive applications that require guarantees for maximal pause time. This work presents a method for reducing the pause time created by compaction at a negligible throughput hit. The solution is most suitable when added to a Mark-Sweep garbage collector. Compaction normally consists of two major activities: the moving of objects and the update of all the objects ’ references to the new locations. We present a method for executing the reference updates concurrently, thus eliminating a substantial portion of the pause time hit. To reduce the time for moving objects in each compaction, we use the existing technique of incremental compaction, but select the optimal area to compact. Selecting the area is done after executing the mark and sweep phases, and is based on their results. We implemented our compaction on top of the IBM J9 JVM V2.2, and present measurements of its effect on pause time, throughput, and mutator utilization. We show that our compaction is indeed an efficient fragmentation reduction tool, and that it improves the performance of a few of the benchmarks we used, with very little increase in the pause time (typically far below the cost of the mark phase).

We describe a mark-scan garbage collection algorithm for variablesized nodes that marks the accessible nodes and compacts the heap only when memory becomes fragmented. For many lazy functional programs, this garbage collector performs much better than a combination of a copying and two-phase compacting mark-scan collector. 1 Introduction Many implementations of lazy functional languages use a copying garbage collector [Che70]. Unfortunately, with such a collector only half the available memory can be used. And when the memory use approaches half the amount of memory, garbage collection becomes very expensive. Therefore, some implementations also use a compacting mark-scan collector [GNS91, San91]. With this garbage collector it is possible to use almost all available memory, but it is slower than a copying collector if the memory use is low. Therefore, some implementations automatically use a copying collector when memory use is low and a mark-scan collector when memory use is high. U...

The garbage collector presented in this paper makes use of two well known compaction garbage collection algorithms with very different performance characteristics: Cheney's two-space copying collector and Jonker 's single-space sliding compaction collector. We propose a scheme which allows either collector to be used. The run-time memory requirements of the program being executed are used to determine the most appropriate collector. This enables us to achieve a fast collector for heap requirements less than half of the heap memory but allows the heap utilization to increase beyond this threshold. Using these ideas we develop a particularly attractive extension to Appel's generational collector.

The Glasgow Haskell compiler provides a foreign language interface which allows Haskell programs to call arbitrary C functions. This has been used both to implement the standard Haskell IO system and a variety of applications including an arcade game [8], and a graphical user interface to a database [19]. The theoretical problems associated with using impure functions from pure functional languages are avoided through the use of monads [17]; and the mismatch between strict languages with no garbage collection and lazy languages with garbage collection is tackled by unboxing (that is, forcing evaluation of arguments and stripping off any header information) [15]. Whilst this works well for simple examples, it is unsuitable when one wants to pass arguments (or results) which are lazy, polymorphic or very large. We describe two extensions to the garbage collector which solve these problems by allowing better interaction between the Haskell garbage collector and memory allocation in the im...

Generational garbage collection is an established method for creating efficient garbage collectors. Even a simple implementation where all nodes that survive one garbage collection are tenured, i.e., moved to an old generation, works well in strict languages. In lazy languages, however, such an implementation can create severe temporary space leaks. The temporary space leaks appear in programs that traverse large lazily built data structures, e.g., a lazy list representing a large file, where only a small part is needed at any time. A simple generational garbage collector cannot reclaim the memory, used by the lazily built list, at minor collections. The reason is that at least one of the nodes in the list belongs to the old generation, after the first minor collection, and will hold on to the rest of the nodes in the list until the next major collection. To completely abandon the idea with generational garbage collection for lazy languages is however an overkill since the fundamental id...

Generational garbage collection is an established method for creating efficient garbage collectors. Even a simple implementation where all nodes that survive one garbage collection are tenured, i.e., moved to an old generation, works well in strict languages. In a lazy language, however, such an implementation can create severe temporary space leaks. The temporary space leaks appear in programs that traverse large lazily built data structures, e.g., a lazy list representing a large le, where only a small part is needed at any time. A simple generational garbage collector can not reclaim the memory, used by the lazily built list, at minor collections. The reason is that at least one of the nodes in the list belongs to the old generation, after the first minor collection, and will hold on to the rest of the nodes in the list until the next major collection takes place. To completely abandon the idea with generational garbage collection for lazy languages is however an overkill since the f...

Self-compiling implementations of Haskell, i.e., those written in Haskell, have been and, except one, are still space consuming monsters. Object code size for the compilers themselves are 3-8 Mbyte, and they need 12-20 Mbyte to recompile themselves. One reason for the huge demands for memory is that the main goal for these compilers is to produce fast code. However, the compiler described in this paper, called nhc for Nearly a Haskell Compiler, is the above mentioned exception. This compiler concentrates on keeping memory usage down, even at a cost in time. The code produced is not fast but nhc is usable, and the resulting programs can be run, on computers with small memory. The low demand for memory in nhc has two causes: carefully chosen algorithms in the compiler, and a memory efficient abstract machine. The former only affects memory demands in nhc, but the latter is a win for all programs compiled by nhc. The memory efficient algorithms used in nhc can be used in other Haskell compilers with no, or very small, changes to their run-time systems. They have only a marginal effect on compile time. The reason for the slow speed is mostly due to the implementation of the abstract machine, a byte coded G-machine. Programs compiled by nhc can produce many different heap profiles to facilitate development of more space efficient programs. One example is nhc itself, where these profiles were used to choose between different algorithms. The current version of nhc includes heap profiling of live objects. These profiles can show the producers, constructors, retainers or lifetimes of the live objects in the heap. A simple time profile is also available. Time is however neither the main focus of nhc nor of this paper, but there is nevertheless a small section about the speed of nhc. The most notable observation concerning speed is that nhc spends approximately half the time processing interface files, which is much more than is needed in, e.g., the type checker. Processing interface files is also the most space consuming part of nhc in most cases. It is only when compiling source files with large sets of mutually recursive functions that more memory is needed to type check than to process interface files.

Although the executable programs produced by the Glasgow Haskell Compiler run quickly, they are considerably larger than those produced by Chalmers' Haskell B compiler. We discuss a means of finding needlessly repeated information as presented in [FMW84]; our application of the results produced by this simple analysis show that the run time storage system is a prime candidate for optimisation. We have coalesced replicated information held in per-closure storage management tables into common tables to reduce the amount of space consumed by the per-closure tables, and changed our garbage collection algorithms to accommodate this. These modifications result in binaries being, on average, 13% smaller than those produced by the unmodified compiler, at an approximate 1% performance penalty incurred at run time. 1 Introduction Executable programs produced by the Glasgow Haskell Compiler (GHC) perform well when compared against those produced by other compilers for functional languages [Har]....