Abstract not found

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

this memory is used during exection to lower the working set of the program. How large part is determined after each garbage collection. The amount is used (i.e., available for allocation) is the amount that was copied when the collection occured multiplied by 4. In this way the working set is adapted to the amount of heap that is actually in use.