On Thu, Jun 9, 2011 at 12:14 PM, Jecel Assumpcao Jr. <jecel@merlintec.com> wrote:

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