[VM] Garbage collection woes when removing compact classes

Dan Ingalls DanI at wdi.disney.com
Mon Apr 12 16:44:49 UTC 1999


Peter -

>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?

As Bob Arning pointed out, lastPointerOf: (and lastPointerWhileForwarding:) accomplish this.

>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.

This is great.  You're following exactly the steps we planned for dealing with contexts independent of their CCI and for generally streamlining that one wrinkle.

>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!

Well, debugging Squeak in the middle of a GC is a bit like using a blender to study frogs.
Sometimes it's the only way, but I always try to avoid it.

I suggest that you put a breakpoint before the GC starts to run and perform some sort of validity check first (I usually override incrementalGC in the InterpreterSimulator, and precede it by self validate).  If it passes, then you may have good objects but a bad GC;  if it fails, then you should have your hands on a bad object, and things should go more easily from there.

If things are messed up all over, then I would suggest running a validity check at every send and return, or even at every bytecode so you catch the problem as early as possible.

Good luck.  Let us know how you make out.

	- Dan





More information about the Squeak-dev mailing list