A compromise approach would be to allow something like Erlang's 
processes to run on each CPU within the same image.  You would still be 
required to copy any object that pass the process boundary, but the 
advantages are separate GC's for each process and the only kernel level 
synchronizations would be via asynch. queues.

It would end up very much like the Hydra model (insofar as I understand 
it), but without the fully IPC context switch.

To avoid confusion, these processes would not map 1-to-1 to Squeak 
processes, which would continue as normal.  These would be special, 
uber-cpu processes.


Michael van der Gulik wrote:
> In the long term, a VM that can run its green threads (aka Process) on 
> multiple OS threads (aka pthreads) should be the long-term goal.
>
> I can't imagine that hacking the VM with multiple processes, 
> per-process state and a global VM lock for garbage collection and new 
> object 
> creation would be too difficult. The global VM lock would kill scalability and could make object creation slow, 
> but it should still get some speedup on multi-cored CPUs. More 
> advanced VMs with per-thread eden space would take a bit longer to write.


-- 
Jeffrey Straszheim
http://straszheim.50megs.com