Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this observation. Optimistic Evaluation complements compile-time analyses with run-time experiments: it evaluates a thunk speculatively, but has an abortion mechanism to back out if it makes a bad choice. A run-time adaption mechanism records expressions found to be unsuitable for speculative evaluation, and arranges for them to be evaluated more lazily in the future.

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)

Abstract not found

Abstract Higher-order languages that encourage currying are implementedusing one of two basic evaluation models: push/enter or eval/apply. Implementors use their intuition and qualitative judgements tochoose one model or the other. Our goal in this paper is to provide, for the first time, a more sub-stantial basis for this choice, based on our qualitative and quantitative experience of implementing both models in a state-of-the-artcompiler for Haskell. Our conclusion is simple, and contradicts our initial intuition: com-piled implementations should use eval/apply. 1 Introduction There are two basic ways to implement function application ina higher-order language, when the function is unknown: the push/enter model or the eval/apply model [11]. To illustrate thedifference, consider the higher-order function

Higher-order languages that encourage currying are implemented using one of two basic evaluation models: push/enter or eval/apply. Implementors use their intuition and qualitative judgements to choose one model or the other.