karl writes:

 > Another issue that will come up in the near future is multi core 
 > processors. What must be done with Squeak to utilize all the processors 
 > and what are the benefits and drawback of the  different approaches ? 
 > What can  the board do to help in this effort ?

The only gain from a multithreaded VM is speed. It seems sensible
to aim to compete with C for scalar performance before moving to
parallelization.

That said, the biggest difficulty with moving the VM to multithreaded
execution is the garbage collector and write barrier. Replacing the 
write barrier with a card marking scheme designed for fast scaler
performance could easily be combined with adding a mostly parallel
old space collector. A mostly parallel old space collector would
remove the number of pauses over a few milliseconds which would
be nice for multimedia type soft real time systems. With a mostly
parallel collector then adding multiple parallel mutators (threads)
should be relatively easy but will expose exciting concurrency bugs
in the image.

For practical use running multiple images is probably the way to go if
you want to scale up. Swarms of Spoons.  SMP machines don't scale that
far. Non-symmetric machines scale further. Grids scale
furthest. Running a GCed system on hardware where you care about how
close the memory is to the CPU you're on is going to create
interesting performance characteristics.

That said, I think we should go multithreaded but there's other things
we should do first. Some of those things will provide most of the
plumbing needed to go multithreaded.

Bryce