Thoughts on a concurrent Squeak VM

Andreas Raab andreas.raab at gmx.de
Wed Oct 31 23:24:10 UTC 2007


bryce at kampjes.demon.co.uk wrote:
> 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.

Yes. Such is the price of shared state concurrency.

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

Given the sensitivity of GC algorithms in real-world situations, 
rewriting the garbage collector is not my understanding of a practical 
approach. The overhead of using an atomic allocator/GC mechanism can be 
reduced to a single decrement and test for the default single-threaded 
case, so that the price would only be paid when you run multiple 
threads. That seems like more straight-forward approach in particular if 
one can tweak the GC parameters to run GC less often (and incur the 
overhead less often).

Cheers,
   - Andreas



More information about the Squeak-dev mailing list