🚀 go-pugleaf

Kevin Hammond writes:

| The Haskell B. (and LML) implementations have (or had) some
| interesting space leaks (as Dave Wakeling's profiler pointed out).
| One of these was due to not "black-holing" closures when they were
| entered (so retaining space if arguments to the original closure
| became dead before the closure was fully evaluated).  It sounds as if
| this may be the problem reported with the Haskell B implementation.
| The most recent implementation has compiler flags to fix the problems
| which Dave Wakeling reported, but I think they're disabled by default
| (black-holing costs time, for instance, which you may not want to
| spend).

I thought the 0.998.* versions of lml/hbc have blackholing
*on* by default.  Anyway, you can turn it on manually
by issuing the flag -fzap-redex to lml or hbc.

I suspect blackholing doesn't cost more than about 5% in performance
terms, but it would be interesting for someone to quantify this.
As I understand it, the Glasgow compiler maintains a stack of
pointers to closures under evaluation, so the garbage collector
can do the redex zapping, rather than impose that cost on the
mutator.  lml/hbc unfortunately has to zap every closure as it
goes along, which is more expensive.

Jules