On Thursday 18 October 2007 10:58 pm, Peter William Lount wrote:
> I propose that any distributed object messaging system that is developed
> for inter-image communication meet a wide range of criteria and
> application needs before being considered as a part of the upcoming next
> Smalltalk Standard. These criteria would need to be elucidated from the
> literature and the needs of members of the Smalltalk community and their
> clients.
>
> 2) It's been mentioned that it would be straightforward to have squeak
> start up multiple copies of the image (or even multiple different
> images) in one process (task) memory space with each image having it's
> own native thread and keeping it's object table and memory separate
> within the larger memory space. This sounds like a very nice approach.
I am not so sure. Squeak VM is a processor hog. Threads within VM will need 
processor for bytecode interpretation. So a VM process can only scale to a 
few threads before it starves for processor. On the downside, coding errors 
could trash object memory across threads making testing and debugging 
difficult. Will the juice be worth the squeeze?
> 3) A single image running on N-cores with M-native threads (M may be
> larger than N) is the full generalization of course.
> This may be the best way to take advantage of paradigm shaking chips
> such as the Tile64 processor from Tilera.
With single or few processors, we tend to "serialize" logic ourselves and 
create huge linear programs. When processors are aplenty, we are free to 
exploit inherent parallelism and create many small co-ordinating programs. So 
the N-cores are a problem only for small N (around 8).
> However, we may need to rethink the entire architecture of the Smalltalk
> virtual machine notions since the Tile 64 chip has capabilities that
> radically alter the paradigm. Messages between processor nodes take less
> time to pass between nodes then the same amount of data takes to be
> written into memory. Think about that. It offers a new paradigm
> unavailable to other N-Core processors (at this current time).
True. Squeak's VM could virtualize display/sensors and spawn each project in 
its own background process bound to a specific processor. The high-speed, low 
latency paths are well-suited for UI events. Imagine running different 
projects on each face of a rotating hexecontahedron :-).

Subbu