Thoughts on a concurrent Squeak VM
Marcel Weiher
marcel.weiher at gmail.com
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
Marcel
More information about the Squeak-dev
mailing list
|