[Vm-dev] Multiprocessing with Squeak

[Josh Gargus]

On Jan 29, 2010, at 12:51 AM, Igor Stasenko wrote:

> 
> On 29 January 2010 08:42, Colin Putney <cputney at wiresong.ca> wrote:
>> 
>> 
>> On 2010-01-27, at 2:04 PM, Levente Uzonyi wrote:
>> 
>>> Hi,
>>> 
>>> I had an idea a few days ago and even though I don't have the time or knowledge to try it myself, I just can't get it out of my head. The idea is to let an interpreter use two images at once. One of them is read only "fully working" image let's call it S (source), the other is empty (contains no objects), writeable, possibly generated on the fly, let's call it W (working). The vm knows if an object is in S or W by checking the object pointer. Whenever an object in S is about to be modified, a copy is created in W and all references to it are changed to the new one (which means that more than one object might have to be copied). This means a slower startup, but once all necessary objects are copied performance would be normal.
>>> (This approach is similar to the way sources are handled today: the sources file is read only, new source code goes to the changes file.)
>> 
>> I believe VW can do something like this - they call it "Shared Perm Space." There's a special section of memory that's immutable, not subject to garbage collection, and shared between several VM processes.
>> 
>>> - combine it with HydraVM, it might give Erlang-like capabilities (cheap
>>>  and fast processes)
>> 
>> Well, we already have cheap and fast processes. The overhead for creating a new instance of Process and scheduling it is very low. What we lack is isolation between them. Squeak seems to be drifting in that direction, though. Islands are a good start. Josh's recent contribution of futures to the trunk are another step away from shared state concurrency.
>> 
>> My sense of it is that efficient use of memory isn't the most important problem to solve at the moment. Further steps toward event-loop concurrency would be more fruitful.
>> 
> Well, at some point we should start using some kind of native-based
> concurrency, not just green threading.
> Processes still run on top of a single object space, i.e. all objects
> are equally reachable from any process since they are using
> non-concurrent memory model.
> Oh, nevermind, we had long talks about it in the past , lets not start
> over again :)

:-)

Modern multi-core/hyper-threaded CPUs present a lot of low-hanging fruit for us to harvest.  I was tickled to learn that my new desktop machine can compile a Squeak VM from scratch in 15 seconds it I let it use 10 threads ("make -j 10").

Hydra seems like the easiest way to do so.  Luckily, it's both orthogonal and complementary to efforts to facilitate event-loop concurrency.  For example, the receiver of a message can be an "eventual reference" (Mark Miller's terminology... I prefer "far-ref") to an object in a different Hydra image: "foo := aRef future bar: baz".  This would result in a Promise being assigned to "foo"; it would resolve once the message executed in the remote image, and communicated the result back via a Hydra channel.

Cheers,
Josh



> 
>> Colin
> 
> 
> 
> -- 
> Best regards,
> Igor Stasenko AKA sig.