Thomas Gagne posted on to a Smalltalk newsgroup and James Robertson replied - about saving an image and the woes of saving lots of live objects which you don't want to save. So, I thought I might throw my two cents in here and imagine a different kind of execution environment to the C-style and the Smalltalk image-style.

Let's say that the running program is mutable (isn't it funny that inside a running Smalltalk application we have the concept of immutable objects). This is a goal of Smalltalk - to be editable while it runs - to change it while it runs. So let's not throw the baby out with the bath water.

Let's also say that "saving the image" is actually undesirable. It adds too much complexity for very little gain. Sure, you can leave your windows where they are in a nice state, etc - but if you're on a laptop you can do that any way.

Let's further say that the way you edit an image and source code is in a development environment, not in the running application itself. In otherwords, you can 'connect' to a running program to edit it - and by edit I mean change code, inspect and alter live objects, debug processes, run arbitrary scripts, etc.

Let's go a step further and say that an application is allowed to have the same namespace and the same class loaded more than once - if they are different versions. (Technically, different versions also the namespace anyway). That way one can have Smalltalk.Core ST1980 and Smalltalk Core 2000 ANSI loaded side by side. This is something you can have done in the C environment for many many years... so let's catch up there.

Did you know that the way most operating systems and execution environments load stuff is by memory mapping it? Why do they do that? so that if some parts of a large program are not actually used, we don't get the penalty of trying to load it. This is the most efficient way to start up a program or link in a DLL. So why can't we do that with Smalltalk images and Smalltalk libraries? (assuming we don't have to transform endianess on startup).

Now let's say that an image and a Smalltalk library have the same on-disk format. That basically means they're both images - or mini-images if you like. So what is a "big image" then? Well, it's the developer linking all the libraries together to make one statically linked application. Static isn't the best choice of words here, since our application is still mutable. In fact, it's mutable up until the point where you tell it not to listen to external connections any more.

In fact, deployment of an application would be just that. If you choose to - glue your libraries together in to a big image - glue on the VM so it is an exe or elf binary or dll library or so library or whatever you wanted to make - then flick the switch so it won't listen for external connections any more. Naturally all of the above steps can be skipped depending on your choice of deployment.

Okay - so back to the issue of image saving. What are we actually saying here? We're saying "This is a bunch of code and here is a bunch of data that goes with the code." -- pretty much the same as any other on-disk executable code format. The traditional Smalltalk image goes further than that, it says "This is a bunch of lots of different code and here is a bunch of data that goes with that different code and here is a bunch more data that was just hanging around which may or may not have been of importance."

Well let's assume that we can live without all the 'other data' that every one else in the computing industry has lived without for decades now. Saving that data isn't, in my opinion, one of the most amazing parts of Smalltalk after all - so let us leave it on the side of the road for now and continue.

Obviously inspecting, debugging, managing processes is a matter of reflection on live objects in the system. There's no biggy there, since we're not even saving them - we can change them in any way we want. Now let's say we want to change the code - we're reading code off of disk and mapping it in to memory. This is highly efficient - so long as the thing doesn't need to be remapped in to memory (which is achievable even with a Smalltalk execution environment).

So new code is actually a new library. It can be entirely in memory and pretend it is on disk. It could be a bunch of overrides of existing code, it could be an entirely new namespace, new classes in an existing namespace, a new version of an existing namespace.. whatever. So, we haven't actually "lost" any features of Smalltalk in this shift - in fact, we've gained a few.

Our on disk format is now something that is "normal" by most industry standards, our startup times will be really really fast and we've also picked up the ability to have multiple versions of stuff in the same executing program. We've also made deployment a lot easier too and we've removed yet another on disk format by making an image and a smalltalk library the same shape.