Andreas,

What about using C++?  There would be some degradation of performance. 
However, there would be the benefit of structuring the VM classes, of not 
having to add VM as an argument everywhere, and it may even be possible to 
subclass Thread so we know where the thread-local storage is.

Rob

----- Original Message ----- 
From: "Andreas Raab" <andreas.raab at gmx.de>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Tuesday, October 30, 2007 8:53 PM
Subject: Thoughts on a concurrent Squeak VM (was: Re: Concurrent Futures)


> Igor Stasenko wrote:
>> If you have any ideas how such VM would look like i'm glad to hear.
>
> Okay, so Josh convinced me to write up the ideas. The main problem as I 
> see it with a *practical* solution to the problem is that all of the 
> solutions so far require huge leaps and can't be implemented step-by-step 
> (which almost certainly dooms them to failure).
>
> So what do we know and what do we actually all pretty much agree on? It's 
> that we need to be able to utilize multiple cores and that we need a 
> practical way to get there (if you disagree with the latter this message 
> is not meant for you ;-) Running multiple processes is one option but it 
> is not always sufficient. For example, some OSes would have trouble firing 
> off a couple of thousand processes whereas the same OS may have no problem 
> at all with a couple of thousand threads in one process. To give an 
> example, starting a thread on Windows cost somewhere in the range of a 
> millisecond which is admittedly slow, but still orders of magnitude faster 
> than creating a new process. Then there are issues with resource sharing 
> (like file handles) which are practically guaranteed not to work across 
> process boundaries etc. So while there are perfectly good reasons to run 
> multiple processes, there are reasons just as good to wanting to run 
> multiple threads in one process.
>
> The question then is, can we find an easy way to extend the Squeak VM to 
> run multiple threads and if so how? Given the simplistic nature of the 
> Squeak interpreter, there is actually very little global state that is not 
> encapsulated in objects on the Squeak heap - basically all the variables 
> in class interpreter. So if we would put them into state that is local to 
> each thread, we could trivially run multiple instances of the byte code 
> interpreter in the same VM. This gets us to the two major questions:
>
> * How do we encapsulate the interpreter state?
> * How do we deal with primitives and plugins?
>
> Let's start with the first one. Obviously, the answer is "make it an 
> object". The way how I would go about is by modifying the CCodeGenerator 
> such that it generates all functions with an argument of type "struct VM" 
> and that variable accesses prefix things properly and that all functions 
> calls pass the extra argument along. In short, what used to be translated 
> as:
>
> sqInt primitiveAdd(void) {
>   integerResult = stackIntegerValue(1) + stackIntegerValue(0)
>   /* etc. */
> }
>
> will then become something like here:
>
> sqInt primitiveAdd(struct VM *vm) {
>   integerResult = stackIntegerValue(vm,1) + stackIntegerValue(vm,0)
>   /* etc. */
> }
>
> This is a *purely* mechanical step that can be done independent of 
> anything else. It should be possible to generate code that is entirely 
> equivalent to todays code and with a bit of tweaking it should be possible 
> to make that code roughly as fast as we have today (not that I think it 
> matters but understanding the speed difference between this and the 
> default interpreter is important for judging relative speed improvements 
> later).
>
> The above takes care about the interpreter but there are still primitives 
> and plugins that need to be dealt with. What I would do here is define 
> operations like ioLock(struct VM) and ioUnlock(struct VM) that are the 
> effective equivalent of Python's GIL (global interpreter lock) and allow 
> exclusive access to primitives that have not been converted to 
> multi-threading yet. How exactly this conversion should happen is 
> deliberately left open here; maybe changing the VMs major proxy version is 
> the right thing to do to indicate the changed semantics. In any case, the 
> GIL allows us to readily reuse all existing plugins without having to 
> worry about conversion early on.
>
> So now we've taken care of the two major parts of Squeak: We have the 
> ability to run new interpreters and we have the ability to use primitives. 
> This is when the fun begins, because at this point we have options:
>
> For example, if you are into shared-state concurrency, you might implement 
> a primitive that forks a new instance of the interpreter running in the 
> same object memory that your previous interpreter is running in.
>
> Or, and that would be the path that I would take, implement a primitive 
> that loads an image into a new object memory (I can explain in more detail 
> how memory allocation needs to work for that; it is a fairly 
> straightforward scheme but a little too long for this message) and run 
> that interpreter.
>
> And at this point, the *real* fun begins because we can now start to 
> define the communication patterns we'd like to use (initially sockets, 
> later shared memory or event queues or whatever else). We can have tiny 
> worker images that only do minimal stuff but we can also do a Spoon-like 
> thing where we have a "master image" that contains all the code possibly 
> needed and fire off micro-images that (via imprinting) swap in just the 
> code they need to run.
>
> [Whoa! I just got interrupted by a little 5.6 quake some 50 miles away]
>
> Sorry but I lost my train of thought here. Happens at 5.6 Richter ;-) 
> Anyway, the main thing I'm trying to say in the above is that for a 
> *practical* solution to the problem there are some steps that are pretty 
> much required whichever way you look at it. And I think that regardless of 
> your interest in shared state or message passing concurrency we may be 
> able to define a road that leads to interesting experiments without 
> sacrificing the practical artifact. A VM built like described in the above 
> would be strictly a superset of the current VM so it would be able to run 
> any current images and leave room for further experiments.
>
> Cheers,
>   - Andreas
>
>
>