[gclist] Tradeoffs in collectors

[Amit J Patel]

I've seen a lot of work done on making GCs fast or incremental.  What
kinds of systems are recommended for saving space (both data and
code)?  

In my case, I'm writing a small DOS application that needs to fit in
300k, so I want to make something really simple that doesn't have a
lot of overhead per object.  I also don't have VM tricks to play with.
A two-space copying collector is out due to space reasons.  :(

I would expect that GCs for small embedded systems would be what I
need:

	- small data overhead
	- small collector code size
	- small address space (no VM)

Unfortunately, I don't know what kinds of GCs, if any, are used for
embedded systems.

BIBOP would probably save a lot of header space.  Which collectors
have a simple implementation?  Are any of these good for interactive
systems?  Overall speed is not a problem, but noticable delays might
annoy people (Emacs comes to mind!).

[I will reread Paul Wilson's Survey Paper this weekend; it's been a few
 years and the last time I read it, I was looking for speed and not
 space.  :) ]

	- Amit


-- 
Amit J Patel, Computer Science Department, Stanford University
             "The works of a lone architect are more elegant 
              than those attempted by several togther."    - Pascal