I'm sure I'm missing something dead obvious here, but I've spent the last 8
hours with my head in the garbage collection code looking for it without
any luck, so...

How does the garbage collection scheme avoid remapping the fields of format
6 objects (indexable words, no pointers; Floats and Bitmaps, for example)
when compacting?  For that matter, how does the mark phase avoid trying to
follow the words of these objects when marking?

I'm trying to eliminate compact classes from my image, as a precursor to
moving to fixed-size headers.  I've patched SystemTracer to write
everything with at least 2-word headers; it appears to be working when
writing out, as all the sanity checks I can devise end up clean.  I have a
version of the Interpreter that doesn't rely on single-word headers for
BlockContext and MethodContext; for now, I've kept the compact class index
to distinguish them, although I suspect there's no need to and I've been
careful to eliminate all other code that uses the CCI.  I've assigned
Contexts a new format (format 5).  I'm working with Tim's NCM image, but
neither he nor I appear to have touched the garbage-collection.

The first garbage-collection (an incremental as the image starts up)
appears to work OK, but the second one falls over part-way through the mark
phase.  It seems to chase a pointer pointing into the middle of a
variable-byte object (actually the String in youngSpace that contains the
full path to the sources file).

So:

- How does the GC avoid marking from, and remapping, the words in indexable
word objects?

- To the folks who have worked with GC algorithms before, does this
behaviour ring any bells?  Suggestions as to how to debug this would be
gratefully received, as this is my first time working with a modern GC.

Any and all ideas welcome!

		- Peter