Lazy functional languages are declarative and allow the programmer to write programs where operational issues such as the evaluation order are left implicit. It is desirable to maintain a declarative view also during debugging so as to avoid burdening the programmer with operational details, for example concerning the actual evaluation order which tends to be difficult to follow. Conventional debugging techniques focus on the operational behaviour of a program and thus do not constitute a suitable foundation for a general-purpose debugger for lazy functional languages. Yet, the only readily available, general-purpose debugging tools for this class of languages are simple, operational tracers. This thesis presents a technique for debugging lazy functional programs declaratively and an efficient implementation of a declarative debugger for a large subset of Haskell. As far as we know, this is the first implementation of such a debugger which is sufficiently efficient to be useful in practice. Our approach is to construct a declarative trace which hides the operational details,

In this thesis we present and analyse a set of automatic source-to-source program transformations that are suitable for incorporation in optimising compilers for lazy functional languages. These transformations improve the quality of code in many different respects, such as execution time and memory usage. The transformations presented are divided in two sets: global transformations, which are performed once (or sometimes twice) during the compilation process; and a set of local transformations, which are performed before and after each of the global transformations, so that they can simplify the code before applying the global transformations and also take advantage of them afterwards. Many of the local transformations are simple, well known, and do not have major effects on their own. They become important as they interact with each other and with global transformations, sometimes in non-obvious ways. We present how and why they improve the code, and perform extensive experiments wit...

If a fixed exponentially decreasing probability distribution function is used to model every object’s lifetime, then the age of an object gives no information about its future life expectancy. This radioactive decay model implies there can be no rational basis for deciding which live objects should be promoted to another generation. Yet there remains a rational basis for deciding how many objects to promote, when to collect garbage, and which generations to collect. Analysis of the model leads to a new kind of generational garbage collector whose effectiveness does not depend upon heuristics that predict which objects will live longer than others. This result provides insight into the computational advantages of generational garbage collection, with implications for the management of objects whose life expectancies are difficult to predict. 1

Abstract not found

Traditional database management systems perform updates-in-place and use logs and periodic checkpointing to efficiently achieve atomicity and durability. In this Thesis we shall present a different method, Shades, for achieving atomicity and durability using a copy-on-write policy instead of updates-in-place. We shall also present index structures and the implementation of Shines, a persistent functional programming language, built on top of Shades. Shades includes real-time generational garbage collection. Real-timeness is achieved by collecting only a small part, a generation, of the database at a time. Contrary to previously presented persistent garbage collection algorithms, Shades has no need to maintain metadata (remembered sets) of intra-generation pointers on disk since the metadata can be reconstructed during recovery. This considerably reduces the amount of disk writing. In conjunction with aggressive commit grouping, efficient index structures, a design specialized to a main memory environment, and a carefully crafted implementation of Shines, we have achieved surprisingly high performance, handsomely beating commercial database management systems.

This paper presents a practical evaluation and comparison of three stateof -the-art parallel functional languages. The evaluation is based on implementations of three typical symbolic computation programs, with performance measured on a Beowulf-class parallel architecture.

We document the design and implementation of a “production” incremental garbage collector for GHC 6.02. It builds on our earlier work (Non-stop Haskell) that exploited GHC’s dynamic dispatch mechanism to hijack object code pointers so that objects in to-space automatically scavenge themselves when the mutator attempts to “enter ” them. This paper details various optimisations based on code specialisation that remove the dynamic space, and associated time, overheads that accompanied our earlier scheme. We detail important implementation issues and provide a detailed evaluation of a range of design alternatives in comparison with Non-stop Haskell and GHC’s current generational collector. We also show how the same code specialisation techniques can be used to eliminate the write barrier in a generational collector. Categories and Subject Descriptors: D.3.4 [Programming Languages]: Processors—Memory management (garbage collection)

Generational collection has improved the efficiency of garbage collection in fast-allocating programs by focusing on collecting young garbage, but has done little to reduce the cost of collecting a heap containing large amounts of older data. A new generational technique, older-first collection, shows promise in its ability to manage older data.

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

Generational garbage collection (GGC) is one of the most popular garbage collection techniques. GGC gains a performance advantage by performing minor collections on the younger objects in the heap, reducing the number of major collections of the whole heap. A promotion policy determines when an object moves from the younger generation to the older. The design of GGC has been justified by the plausible assumption that many objects die very young, and a few live a very long time. But, attempts to tune the performance of GGC by adjusting the promotion policy have been disappointing—only the simplest immediate promotion policy has proved attractive. The success of GGC is probably due to simplicity and to avoiding scans of the whole heap, rather than to accurate lifetime predictions. This paper presents Leveled Garbage Collection (LGC), a new algorithm that is not based on object ages. It uses a heap structure and collection scheme similar to those of generational garbage collectors, and has a non-age-based promotion policy that doesn’t promote all of the live objects, but still guarantees ample free space immediately after each garbage collection. By tuning LGC’s promotion policy, we can often improve on GGC with immediate promotion. Performance comparisons show that LGC outperforms GGC with immediate promotion policy in many cases, while losing only slightly on cases favorable to immediate promotion. LGC has a substantial advantage when the heap fits in main memory, and an even greater advantage as the heap gets paged to disk. 1 1