When you call a function like this
f 42 (g x y)
then the runtime behaviour is something like the following:
p1 = malloc(2 * sizeof(Word))
p1[0] = &Tag_for_Int
p1[1] = 42
p2 = malloc(3 * sizeof(Word))
p2[0] = &Code_for_g_x_y
p2[1] = x
p2[2] = y
f(p1, p2)
That is, arguments are usually passed as pointers to objects on the heap like in Java, but unlike Java these objects may represent suspended computations, a.k.a. thunks, such as (g x y
/p2
) in our example. Without optimisations, this execution model is quite inefficient, but there are ways to avoid many of these overheads.
-
GHC does a lot of inlining and unboxing. Inlining removes the function call overhead and often enables further optimisations. Unboxing means changing the calling convention, in the example above we could pass
42
directly instead of creating the heap objectp1
. -
Strictness analysis finds out whether an argument is guaranteed to be evaluated. In that case, we don’t need to create a thunk, but evaluate the expression fully and then pass the final result as an argument.
-
Small objects (currently only 8bit
Char
s andInt
s) are cached.That is, instead of allocating a new pointer for each object, a pointer to the cached object is returned.Even though the object is initially allocated on the heap, the garbage collector will de-duplicate them later (only smallInt
s andChar
s). Since objects are immutable this is safe. -
Limited escape analysis. For local functions some arguments may be passed on the stack, because they are known to be dead code by the time the outer function returns.
Edit: For (much) more information see “Implementing Lazy Functional Languages on Stock Hardware: The Spineless Tagless G-machine”. This paper uses “push/enter” as the calling convention. Newer versions of GHC use the “eval/apply” calling convention. For a discussion of the trade-offs and reasons for that switch see “How to make a fast curry: push/enter vs eval/apply”