Concurrency

I'm depressed.

Over the last couple of weeks, I've been playing with various Smalltalk implementations. I always had this idea that some of them could use multiple CPU cores. As it turns out, none of them do it, and the ones that do concurrency don't do it well.

VisualWorks is single-threaded. Squeak is single-threaded. Smalltalk/X didn't fully use two CPU cores. Smalltalk/MT should, but didn't. Huemul 0.7 tried... but crashed.

[update: Smalltalk/MT does use multiple cores as Peter Lount points out in the comments, but is severely limitied by the garbage collector.]

Igor's Hydra VM does concurrency the hard way: by making a completely separate VM in a separate thread but in the same process (using OS terminology here): VMs can communicate with each other, but each is single-threaded. Gemstone, I hear, can make multiple Gems which share a transacted memory, but each Gem is single threaded.

Surely it can't be that hard to make a VM that does fine-grained concurrency?

Smalltalk, the language, is ideally suited to concurrency. The language lends itself to creating concurrent abstractions and already has basic support, but there's no implementation which can take advantage of the CPU power.

Smalltalk VMs are not going to be running any faster if we don't start exploring concurrency. The free ride in MHz increases is about to end soon (in theory, anyway). Moreso, the best Smalltalk VM can only use quarter of the power of a quad-core CPU, and this unused potential will increase exponentially as the number of cores increases exponentially.

What am I going to do about it? Well, I'm going to be modifying the Process scheduler in Squeak to simulate multiple CPU cores. Individual Processes will have their speed throttled down so that using multiple forked processes will be required to get a speed increase. Then I will, eventually, start writing concurrent frameworks to take advantage of the "multiple cores". This way, if some smart alec makes me a nice concurrent VM, they have concurrent code to take advantage of it.

SecureSqueak - what is it exactly?

I've decided to start a blog about SecureSqueak, and maybe other Smalltalk-related topics.

SecureSqueak is Squeak modified to run untrusted code. Code should be able to be loaded from a remote site and executed locally without any damage or unauthorised access to the local system. It is intended to be a kernel for my other unnamed project which is currently going by the name of "Unnamed Grand Project".

SecureSqueak has been in stasus for a while while I pursued a rather less worthy topic: Warzone 2100. Yes, I wasted a few hours of my life!

So now I'm back in action. The next few items on the agenda are:

• Get Subcanvas working. Subcanvas is an enhanced version of the Canvas class which will provide the basic graphics and input handling to SecureSqueak. Subcanvas is also a test bed to see how well I can write code using my recently developed Namespaces for Squeak.
  
• Write another simple SiteBrowser package. This isn't part of SecureSqueak but rather the UGP. This will let the user navigate through distributed objects.
• Get the package distribution (i.e. remote code loading) for UGP working.

Igor Stasenko provided some valuable feedback on the design of Namespaces. Once I've finished the above, I'll be looking at refactoring the namespaces system and put the code for managing namespaces, classes and methods in a namespace itself. Currently the code for managing namespaces sits in the SystemDictionary and is saved at http://squeaksource.com/SecureSqueak, but I eventually plan to deprecate and perhaps even remove the SystemDictionary from the image.

Want to see the code? Well, it's scattered all over the place:

Documentation is at http://gulik.pbwiki.com/.
Code in the SystemDictionary (i.e. most of it) is at http://squeaksource.com/SecureSqueak/.
Code in Namespaces and image files are stored at http://securesqueak.sourceforge.net/.