> Sure. There was a great demo of this on the translator's list for the
> O'Reilly book; create a representation of stacks based on arrays with a
> top of stack index. Popping items off of the stack by moving the TOS
> pointer around won't free them. Could you be doing something like that?

In that particular case, the stack implementation is a lot uglier when you
need to provide the ability to neutralize array elements of arbitrary type
as you pop the stack.  Sometimes you get lulled into thinking the GC works
completely invisibly.

Lisp Machines had special versions of GC that would first run through a list
of GC user-definable initializers that would clear off history lists and
other places that tended to accumulate garbage.  With each new release, new
garbage gatherers and problems like the stack implementation above needed to
be tracked down and adjusted or added to the list.  You get so you notice
that kind of code and automatically unhook pointers when you're done with
them.

I think I caused the biggest leak when I added a compiler optimizer that
removed reads for values that were never used.  One part of this special
garbage collection process played some GC space games and required a memory
read to start the garbage collector, so we had to introduce read for effect.

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners