Andreas Raab writes:
 > Ralph Johnson wrote:
 > > That is a very interesting plan, Andreas.  However, I don't see
 > > garbage collection on the list.  Won't you have to make a concurrent
 > > garbage collecter?
 > 
 > I don't think so. First, you don't need a new garbage collector for the 
 > direction that I would take. Since the threads don't operate on the same 
 > object memory, no change to the collector is needed. And for shared 
 > state concurrency, simple solutions (like a gc request flag per thread 
 > which is checked on each send) can be used to ensure atomic operation of 
 > the collector.

You'd need to serialise object creation and accessing the root table
in the write barrier. That may be possible without too much work but
there's likely to be some overhead.

Providing a parallel object memory as part of a garbage collector
rewrite that speed up single CPU code should be possible. The major
design change would be changing the write barrier from a remembered
set to card marking. That unfortunately might make it necessary to 
separate pointer object space from byte storage space.

>From the reading I did when tuning Exupery's memory access, it looks
like a mostly parallel old space collector should be about the same
amount of work as writing an incremental collector. The trick is to
only run the big mark phase and the big sweep phase in parallel with
the interpreter then stop the interpreter to do the final marks.

That said, share nothing scales to multiple computers. If you
really need CPU power it's often cheaper to buy many smaller
boxes than a few big ones.

Bryce