notes on garbage collection for the reference implementation:

Almost certainly, the garbage collector will end up relocating
objects.  Since the C stack has to be considered a root, pointers on
the stack would have to be relocated.  There is no good way to
differentiate between pointers and integers which happen to be valid
pointers, and changing the value of an integer is unacceptable.  This
means that either all stack references have to go through an
intermediate handle (and cannot cache the handle target across
function calls), the garbage collector must not relocate objects, or
the garbage collector must not be called with an unknown pointer
configuration on the stack.

The handle scheme would be defeated by a good compiler unless there is
specific support for it.  This seems beyond the scope of a reference
implementation.

I propose a mixture of two garbage collectors.  An emergency collector
which is called with pointers on the stack, and which does not
relocate objects, combined with a relocating collector which is only
called when the stack is safe.

The relocating collector is called whenever the free space drops below
a target threshold at an event boundry.  It is also called whenever
the previous event delivery caused the emergency collector to be
activated.  The threshold can be soft, allowing adjustment of the
relocating collector's execution to a timer event pause.

I want the ability to perform a relocation followed immediately by a
write of the heap to an external file.  On restart, the file would be
read, relocated, and resumed.  This, along with improved locality of
reference are the reasons to use a relocating collector.

The allocator would have to know if it can allocate from a contiguous
free block, or if it has to search a free list.  The default (fast)
case should be the contiguous allocation.

From a locality of reference point of view, I prefer a sliding
collector rather than a multi-space copying collector.  Both the
sliding collector and the emergency mark-sweep collector will require
a mark phase.  I want the mark phase not to use a potentially
unbounded stack, so it must either do pointer reversal, or use an
extra field in the object header for the stack.  A sliding collector
seems to require an extra field, which can be used by the mark phase.
The problem with this is that it dirties the page being marked.  That
extra word can be kept in a separate data structure, but that may
double the overhead to two words.

There are at least four types of objects:  objects containing pointers
to other objects, those containing bits, weak references, and
finalization references.  These can be distinguished either by flag
bits in the size field, or by address.

The size field should be distinguishable from a pointer.  This may
allow us to skip storing the count of remaining fields to be examined
by the mark phase, by allowing the reverse pointer to point into the
middle of a partially traversed object.