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)

We describe an ecient technique for incorporating Baker's incremental garbage collection algorithm into the Spineless Tagless G-machine on stock hardware. This algorithm eliminates the stop/go execution associated with bulk copying collection algorithms, allowing the system to place an upper bound on the pauses due to garbage collection. The technique exploits the fact that objects are always accessed by jumping to code rather than being explicitly dereferenced. It works by modifying the entry code-pointer when an object is in the transient state of being evacuated but not scavenged. An attempt to enter it from the mutator causes the object to \self-scavenge" transparently before resetting its entry code pointer. We describe an implementation of the scheme in v4.01 of the Glasgow Haskell Compiler and report performance results obtained by executing a range of applications. These experiments show that the read barrier can be implemented in dynamic dispatching systems such as the STG-mac...

This document summarises crucial information about the RTS. It focusses on the parallel version of the RTS, also known as GUM. It is meant to be used as a kind of survival sheet for the RTS hacker. 1 Papers You Need to Survive The design of the new ( 4.00) GHC runtime system (RTS) is discussed in [8]. It discusses sequential and concurrent compilation and execution. The documentation on the new RTS in the GHC distribution [6] is far more detailed and a must-read for the serious RTS hacker. The design of GUM itself is discussed in detail in [9]. Several other papers on the GPH web page [3] discuss details of the RTS such as graph packing etc. Information on how to install and use GPH can be found on the GPH web page [3] and the GHC User's Guide [1]. A good general overview of the compiler is given in [5], although that paper is rather old by now. Several important GHC transformations are discussed in [7]. The STG machine, i.e. the abstract graph reduction machine we extend in order to perform parallel computation, is discussed in [4]. Most of these papers are available from Simon PJ's web page [2] or from the GPH web page [3]. 2 A Roadmap of the GUM code in the RTS 2.1 Memory management: Several include les in ghc/includes describe the closure layout (discussed in more detail in Section 3): ClosureTypes.h List of all available closures Closures.h The closure layout as typedefs Some crucial properties of closures are speci ed in the global array ClosureFlags de ned in ghc/rts/ClosureFlags.h. The routines for checking these ags are macros de ned in ghc/includes/InfoTables. The macros have the form closure HNF(c) or ip HNF(ip) etc. 1 The layout of InfoTables (StgInfoTable) is de ned in ghc/includes/InfoTables.