Hi folks!

John M McIntosh <johnmci at smalltalkconsulting.com> wrote:
[SNIP]
> think interesting things would happen. An easier solution as Tim points  
> out is to run 2 or 5 or 1000 images and distribute/share data via  
> sockets or even shared memory. I recall once hearing about a Gemstone  
> solution that used shared memory, to enable the sharing of mostly  
> static data 100MB+ across lots of images. That reduced the overall  
> footprint on the server by lots.

GemStone has a VM plus a whole bunch of other processes running in a
shared-memory-pages-scheme with a transaction model keeping it all in
synch.

The net effect is that multiple VMs share (through transactional
replication) "an image" or what is often referred to as an object
memory. This means there is no "automatic" parallellism in actual
*computation* going on - I mean, you still have to turn your Smalltalk
code into multiple processes/threads - which your post also explained,
just wanted to stress it once more. But at least a multitude of VMs can
run (each on its own CPU and possibly own box) sharing the same object
space in a coordinated fashion.

This is of course also what Magma/GOODS etc can give you - a shared
transactional memory.

Given my limited knowledge in the area it seems that the semantics of
message passing would have to be changed in order to get "automatic full
scale" parallellism. Typically each object would execute in its own
Process and messages would be asynchronous. I also assume these lines of
thought is what SqueakELib
(http://map1.squeakfoundation.org/sm/packagebyname/squeakelib,
www.erights.org), Croquet in some way and also Tweak is experimenting
with.


regards, Göran