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