cyclone/gc-notes.txt

Phase 1 (gc-dev) - Add gc.h, make sure it compiles.
Phase 2 (gc-dev2) - Change how strings are allocated, to clean up the code and be compatible with a new GC algorithm.
Phase 3 (gc-dev3) - Change from using a Cheney-style copying collector to a naive mark&sweep algorithm.
Phase 4 (gc-dev4) - Integrating new tracing GC algorithm, added new thread data argument to runtime.
Phase 5 (gc-dev5) - Require pthreads library, stand cyclone back up using new GC algorithm.

memory corruption
 - noticed that an object may be allocated with the old mark color, and then freed before it
   can be marked, even though it is part of a global list.
   what might be happening is that the new heap obj is part of the global list, but the minor
   GC only marks gc-cont/gc-args, which this is not part of. and the globals are already marked
   at that point by the collector thread, so no one is around to mark this object.
   wait a minute - but how does the obj even get on the heap? see this - if above was true there would be no ref to move this to the heap, right? so what is going on?? ->
alloc 0xb78400e0 size = 32, obj=0xbffcd648, tag=0, mark=1
well, we also move globals, which would explain it since the next lambda becomes the head of the global list. so I think that explains it. the most expedient change is to just use moveBuf to mark the thread's roots.

but again, this did not fix all crashes, so there are either other issues with the GC (not surprising, although disappointing) or this is not the issue. but I think this has to be a problem given the error output observed today.

TODO:
- need to fix memory corruption bugs
- need to cooperate when a mutator is blocked
- need an intelligent scheduling of GC, instead of just constantly running it
- add_mutation will need to be brought into thread local data. 
- probably exceptions too. anything else?
- multiple mutators, and threading functions/types.  probably want this on a new branch, when ready