Thoughts on a concurrent Squeak VM

Marcel Weiher marcel.weiher at
Thu Nov 1 03:33:49 UTC 2007

On Oct 31, 2007, at 6:00 PM, Andreas Raab wrote:

> tim Rowledge wrote:
>> Yes, we could probably rewrite a lot of code currently in C source  
>> files and put it into Slang methods. Yes, we could probably improve  
>> Slang (we tried to get some of that done at Interval but ran out of  
>> time) to be more friendly. Yes, we could do lots of things. Got  
>> time to do them? Or money to pay me/Craig/Andreas/Ian/John/Mike/ 
>> Bryce/whoever to do it fulltime? That's the kind of thing that  
>> would be required to be able to make any major changes
> Well, but let's not throw out the baby with the bath water.  
> Improvements would be welcome, in particular if they are easy to  
> review and to integrate. It is probably unwise to start this as the  
> lets-rewrite-the-vm-and-its-tools-from-scratch approach but there  
> are plenty of things that we could do better. For example, I would  
> welcome a patch that enables the code generator to optionally build  
> the entire VM as an object. That'd be a very nice stepping stone  
> towared a multi-threaded VM and can probably be done in a fairly  
> incremental way.

I had some code a while ago that generated the entire VM as an  
Objective-C object, with the actual class hierarchy (ObjectMemory ->  
Interpreter  ) still intact.  It interpreted a couple of thousand byte  
codes until it hit a function that had been generated from literal C  
code embedded in the Smalltalk code for the VM.  I gave up at that  
point because there turned out to be quite a bit of that literal code  
that would need to be rewritten, as it would probably need to be for  
any such effort unless these C snippets have since been replaced.

Now that we seem to  be seriously discussing turning the VM into an  
object, I would suggest at least having a very close look at  
leveraging Objective-C, and yes, I can hear the virtual groans ;-)   
Anyhow, here it goes:

First, unlike the C++ approach there are no problems in terms of  
linkage compatibility:  Objective-C behave just like C in that  
respect.  I also don't see any speed issues, because Objective-C  
methods are just C functions with some extra metadata and some  
implicit arguments.  So functions can still be called and inlined  
pretty much exactly the way they are now.  (This would entail either  
generating the functions and adding the metadata to make them known to  
the runtime or generating methods and getting function pointers from  
the runtime.  Either approach would work, with the former possibly  
retaining better C compatibility).

Speaking of compatibility:  despite the rumors, Objective-C is not an  
Apple/MacOS-X thing.  It comes with gcc and AFAIK most every 32 (and  
64?) bit platform gcc supports.  Furthermore, as I alluded to before,  
and unlike C++,  Objective-C isn't really a new language per-se, it  
really is just C with an object-runtime library that works just as  
well from C and largely optional syntactic sugar.

So if there's so little difference, what's the upside?   Well, the  
runtime does come with all or most of the niggly details you need for  
on OO system.  So on the purely practical side, you can instantiate  
multiple objects (interpreters, plugins), load classes (plugins  
again).   If you have multiple instances of the interpreter, you can  
also have subclasses of the interpreter, override methods on-the-fly,  
do introspection etc.  Plugins can be just objects, with the plugin  
interface regular messages sends.  Etc.

Then there's all that with syntactic and semantic similarity, passing  
messages between the VM and the programs it is running (nice  
metacircularity...) and so on and so forth.

Anyway, just my € 0.02


More information about the Squeak-dev mailing list