On Thu, Jun 9, 2011 at 12:14 PM, Jecel Assumpcao Jr. jecel@merlintec.comwrote:
Eliot Miranda wrote on Wed, 8 Jun 2011 10:01:17 -0700
When Squeak was implemented it was decided to use flat objects in the VM, following the lead of David Ungar's Berkeley Smalltalk implementation,
and of
the subsequent Self implementations, all of which also use flat objects.
Given the background you mention and that all Vector objects in Self (Array in Smalltalk-80) can have named slots as well as indexed ones, you would think that the use of flat objects would be popular. But they are actually very rare. Methods objects, for example, have a named variable called "literals" that holds a Vector and another variable named "bytecodes" that holds a ByteVector. The same is true for the various kinds of Collections.
Are you sure that Self allows named and indexable slots? What's an example in Self?
Flat objects makes for faster allocation and faster inst var access
(since
accessing an inst var doesn't require the double indirection of following
the
pointer to the header and then the pointer to the body). But it makes
become
very much more expensive, since in the worst case the VM must scan the
entire
heap looking for references to the objects in the become operation and replacing them by references to their corresponding objects.
In theory there is no become in Self. In practice, the various object building primitives (such as _AddSlots: or _RemoveSlots:) do their work in place and so have the same cost as become. They are normally invoked by the user from the GUI and not used programatically, so their performance isn't too critical (and scanning the entire heap is the most optimized operation of all, obtained by a special tag for header words and by allocating bytes and pointers from different ends of the heap).
The solution David Ungar developed, which was adopted by Squeak, was to unflatten objects that used become to grow, such as OrderedCollection,
Set
and DIctionary, and use an array to hold their variable part.
Do you mean at runtime or at design time (converting the image once)? If the latter, I had the impression that this was first proposed at Tektronix (after the versions described in the green book). But I don't trust my memory on this.
Im sure it was incremental. There is a full become: in BS but its slow and hence to speed the system up changes were made to certain core classes to reduce becomming. IIRC these changes were available in a change set called unbecomming.st :)
cheers Eliot
-- Jecel
Eliot,
Are you sure that Self allows named and indexable slots? What's an example in Self?
I'm pretty sure, but can't reach my copy of Craig Chambers' thesis right now and it doesn't seem to be available online. None of the other documentation mentions this. Sadly, Self 4.4 is now generating a segfault on this machine (my Fedora 10 installation is causing lots of problems like this). But looking at the Self sources (not VM) for 4.1.6 it seems that "processStack" is created by cloning a vector, removing the "parent" slot and then adding "cache", "format", "myProcess" as data slots and then "parent" as a constant parent slot. In the old UI1 experiment (Morphic is UI2) something similar is done for object "enumResult". Like I said, this is rarely used (these were the only examples I found).
Do you mean at runtime or at design time (converting the image once)? If the latter, I had the impression that this was first proposed at Tektronix (after the versions described in the green book). But I don't trust my memory on this.
Im sure it was incremental. There is a full become: in BS but its slow and hence to speed the system up changes were made to certain core classes to reduce becomming. IIRC these changes were available in a change set called unbecomming.st :)
It is very common for people to get excited by a new feature (like become in Smalltalk-78 or dynamic inheritance in Self) and try to use it as much as possible, even where "conventional" solutions would be as good or even better. Eventually it either dies out or is limited to where it makes sense.
-- Jecel
vm-dev@lists.squeakfoundation.org