Abstract

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.

Citations