[self-interest] Re: Clustering in Self ?

[Jecel Assumpcao Jr.]

David Ungar wrote:
> The Self transporter (I think) does support the modules as orthogonal 
> to classes view a bit better than Smalltalk, although ST does have 
> change files.

I was talking about the change files, since that is how most software seems to
be distributed in the Smalltalk community. You can go to the system browser and
select "FileOut" for a given class (which is a way to bind "modules" and
classes closely together), but that isn't as common.

Change files are just the input side of the equation, of course. You need some
kind of data structure telling you for each element into which module it should
go. Squeak has this in the form of "change sets". I haven't paid much attention
to these, however, and it may be that other Smalltalks have something similar.

The only thing really limiting the independence of classes and modules is that
Smalltalk defines a class with a method like this:

 Object subclass: #CrashTestDummy
                instanceVariableNames: 'instVar'
                classVariableNames: ''
                poolDictionaries: ''
                category: 'Crash-Test'.

So if different change files tried to define a different set of instance
variables (data slots) there would be a big mess. It would be easy to create a
new method like this:

 Object subclassAddIfAbsent: #CrashTestDummy
                addInstanceVariableNames: 'instVar'
                addClassVariableNames: ''
                addPoolDictionaries: ''
                category: 'Crash-Test'.

With a nicer interface for change sets, you would have roughly the same
funcionality as the Self transporter. All that would be missing would be a way
to file out object instances and to specify how their instance variables should
be initialized (constant value, follows slot and so on). Since Smalltalk apps
are developed in a much more restrictive style than Self (classes must have an
#initialize method which is invoked just once and must not have instances if
their "format" is being changed) this missing functionality wouldn't be missed.

> If the original question was about objects in memory, of course the 
> VM does put all the data for a given object in one place, and the 
> old-space collector does tend to move related objects together. This 
> was studied for Smalltalk while I was at Berkeley and there are some 
> (hard-to-find) papers about it.
> We called it "offline reorganization" since in those days it was so 
> slow you couldn't wait for it.

Well, the Mushroom papers I mentioned in my previous email claimed that the
"breadth first tree walk" of copying garbage collectors tends to put most
objects in separate pages from their parents and that this causes problems. You
can fight it out with Mario ;-)

Speaking of slow, even on fast machines the garbage collection for the old space
takes too long. If it happens in the middle of playing a song or showing an
animation, it can be rather nasty.

-- Jecel