Nhc: a Space-eecient Haskell Compiler

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 eecient abstract machine. The former only aaects memory demands in nhc, but the latter is a win for all programs compiled by nhc. The memory eecient 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 eeect 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 diierent heap prooles to facilitate development of more space eecient programs. One example is nhc itself, where these prooles were used to choose between diierent algorithms. The current version of nhc includes heap prooling of live objects. These prooles can show the producers, constructors, retainers or lifetimes of the live objects in the heap. A simple time proole 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 les, which is much more than is needed 1 Garbage collection, and memory eeciency, in lazy functional languages in, e.g., the type checker. Processing interface les is also the most space consuming part of nhc in most cases. It is only when compiling source les with large sets of mutually recursive functions that more memory is needed to type check than to process interface les.