[gclist] Garbage collection FAQ.

[David Gadbois]

      Reference counting.

Is it a good idea to valorize reference counting by putting it first and
at the same level as the other approaches?  The myth to the effect that
"GC is reference counting, reference counting sucks, therefore GC is
bogus" is pretty widespread.

      Copying-compacting.

	Copying collection attempts to collect memory by removing all
	active memory from a storage arena, and then reusing the arena.
	This has the theoretical advantages of compacting the working
	set of an application, and of being asymptotically more
	efficient (because the cost of the collection is only
	proportional to the size of the reachable data, and is unrelated
	to the size of the arena itself.  Mark-and-sweep collection must
	scan the arena).

	However, theory and practice disagree (in practice).  See "Folk
	Myths".

What is the disagreement?  Other than the pig-in-the-poke problem, and
all other things being equal, copying has been a win over mark-and-sweep
as far as I have seen in practice.

      Hardware Support (Kelvin Nilsen's and others).

Good VM hardware support for read or write barriers.
Cache sub-block allocate on write.
Memory pre-fetch (for scanning/scavenging).
Control of caching/non-caching at different cache levels.

    > OS Support.

Access to VM hardware support for read or write barriers.
Fast traps for read or write barrier violations.
Backing store pre-fetch.
Support for dropping dirty in-core condemned page frames.

    Folk myths?

GC is necessarily slower than manual storage management.
GC is reference counting.

--David Gadbois