Musing out loud... [Why not Smalltalk?]

Piercarlo Grandi pg_nh at sabi.Clara.co.UK
Thu Apr 19 20:43:48 EDT 2001


>>> On Wed, 18 Apr 2001 02:42:41 GMT, "James A. Robertson"
>>> <jarober at mail.com> said:

>> "Piercarlo Grandi" <pg_nh at sabi.Clara.co.UK> wrote in message
>> news:yf366g3awne.fsf at sabi.ClaraNET.co.UK...

>>> Thus I find it a bit bizarre to imagine that "it took the Anamorphic
>>> team to pull them all together and prove that they worked in concert",
>>> because the Self group not only largely developed them, but they did
>>> that themselves (actually it was mostly just one guy for the
>>> Smalltalk-80 clone) and in the most straightforward way possible.

jarober> There's also this: Self took SCADS of memory to do it's thing,

Ahhh, not necessarily: Self takes a lot of memory to do _anything_
because it has a pretty extensive, diffuse environment, like many other
memory hogging workspace based languages. Part of the Self group
research therefore has been some fairly interesting work on treeshaking
(e.g. Ole Agesen's) that huge environment. This seems to work reasonably
well.

jarober> while HotSpot was relatively lightweight.

Uhmmm, perhaps Anamorphic's original HotSpot, but the HotSpot in the
current Sun Java stuff takes lots of memory.

jarober> The funny thing is, Sun had to do a lot of work anyway -
jarober> optimizing tricks for Smalltak are not equivalent to optimizing
jarober> tricks for Java

That's well true; but in the case of the Self stuff, it did turn out
that what is good for Self is really good for Smalltalk-80. I think this
happened because Self optimisation problem after all looks like a subset
of the Smalltalk-80 optimisation problem.

The Self optimisation stuff also applies, for much the same reasons, to
to Java as it did to Smalltalk-80 (but with a bit more effort).

The Self/Kanban groups at Sun have published a couple of papers on the
Java-in-Self implementation they did a few years ago:

  http://WWW.Sun.com/research/java-topics/pubs/97-pep.ps
  http://WWW.Sun.com/research/kanban/oopsla-vm-wkshp.pdf

and it looks like they did not have many problems with either
Smalltalk-80 (one month) or Java (six months -- it required some VM
implementation changes, but apparently no real changes in the adaptive
compilation technology).

After all the adaptive compilation technology mostly deals with
optimising away dynamic overload resolution, and this applies to all
languages that rely on it extensively.

As to Java, it has 'final' which should help the compiler quite a lot
even without adaptive technology. But I somehow suspect not a lot of
Java code does make use of it.

Objective-C of course can do something like 'final' more or less by
hand, but perhaps it would be interesting to add something like that to
the language, to minimize the need to switch into the C subset.



More information about the Python-list mailing list