>>> 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4