| > I remember this discussion of a
| > so-called "special rule" for ForeignObjs from previously, and I still
| > don't understand why it is "special" rather than the obvious and only
| > way to do things.
|
| In case of a tail call to a C routine, ghc could deallocate the stack
| frame of the caller (which might hold the last reference to the
| ForeignObj) _before_ calling C.
Yes, I understand that now. Simon Marlow has identified the mechanism
as part of black-holing, i.e. the runtime optimisation intended to
prevent certain sorts of space leak.
nhc98 implements a G-machine, so (to a first approximation) function
arguments live on the stack until the call returns. ghc implements an
STG-machine, where the function arguments live in the heap closure, not
on the stack.
Black-holing is where the runtime system overwrites an object with a
special marker to indicate that it is under evaluation (this helps to
detect infinite loops, as well as potentially releasing storage early
that would otherwise continue to live until the function returned).
ghc and nhc98 differ in what they black-hole - ghc overwrites the
entire closure, while nhc98 only overwrites certain stack positions and
specifically cannot overwrite unboxed values (such as ForeignObjs).
| In some sense, it is nhc's lack of tail call optimisation
No, it is not the tail-call optimisation as such (nhc98 has that),
but it is related.
Thanks everyone for clearing that up for me.
Regards,
Malcolm
