Tim Rowledge writes:
 > I'm very curious how it is proposed to make GC work in parallel to 
 > normal operation. Given the absolute need to keep the object memory
 > in a sane state at any time the execution of code is proceeding 
 > (which is why using native threads is difficult in the first place)
 > how could we be moving object data around whilst another thread (or
 > many - remember the urgent, vital need for native threads) is
 > relying upon the oops and pointers.

The idea was to do most of the old space GC concurrently but not
all. New-space collection would not be done while the interpreter was
running (just like now).

Old space would be collected by a noncompacting mark and sweep
collector. Most of marking can be done concurrently, the write barrior
will record anything that the interpreter changes so it can be
rescanned later. The final few modified objects will be marked while
the interpreter isn't running.

Sweeping can be done concurrently because it doesn't modify live
objects. Objects shouldn't often be allocated directly into old space.
If they are then they should be marked as live to avoid sweeping them.

The key insights I got from the papers were: New space shouldn't be
collected while the interpreter is running. Most of the old space GC
can be done while the interpreter is running. Mostly concurrent is
much easier than fully concurrent.

The two papers that I was thinking about are:
"A Generational Mostly-concurrent Garbage Collector" by Tony
Pritezis and David Detlefs and "A Comparative Evaluation of
Parallel Garbage Collector Implementations" by Clement R. Attanasio,
David F. Bacon, Anthony Cocchi, and Stephan Smith. 

But a concurrent garbage collector for Squeak would probably involve
heavily reworking the entire GC and possibly the image format. This
might be worthwhile after Exupery is in widespread use if garbage
collection becomes a significant bottleneck. My interest was from
thinking about uniprocessor collection performance including the write
barrior. Concurrency might not be much more work than just optimising
uniprocessor garbage collection. But a useful JIT is first.

Bryce