[Vm-dev] What are classes defined with varibleSubclass?

Eliot Miranda eliot.miranda at gmail.com
Wed Jun 8 17:01:17 UTC 2011

On Wed, Jun 8, 2011 at 8:35 AM, Javier Pimás <elpochodelagente at gmail.com>wrote:

> Hi, this is another simple (I hope) question:
> I have an instance of MethodDictionary, which is defined as
> Dictionary variableSubclass: #MethodDictionary
> instanceVariableNames: ''
>  classVariableNames: ''
> poolDictionaries: ''
> category: 'Kernel-Methods'
> looking at the format field it says 3, which I understand is that instances
> have both fixed and indexed oops. The question is, what does that mean? or
> better why is it that way if the class only defines an array an a tally as
> instance variables?

An object with both named and indexed inst vars is flat, i.e. is only a
single object.  For example MethodContext.  An object with an array to hold
its variable objects, e.g. the current OrderedCollection, is not flat, i.e.
two objects.  The distinction is to do with the efficiency of implementing
become.  In the original Smalltalk-80 implementations and in the VisualWorks
VM objects in the heap are split into a header and a body, with the header
containing a pointer to the body (and references to objects are pointers to
object headers). This makes certain algorithms like compaction easy to
implement, but it also results in a cheap become.

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.
 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.
 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.

A key point is that objects such as OrderedCollection, Set and DIctionary
encapsulate their state and so are free to grow by allocating a larger array
and copying the contents from the old to the new array.  There is still an
issue with streams, which have also been changed not to use become when
growing their collections.  It used to be the case that one could use
streams to grow objects, since in Smalltalk-80 they used become.  But this
was not used very often and easily worked around.


> Also, looking at the header, I see some strange things in the size field
> (being bigger than what I'd expect). What is the format of size field in
> this case?
> Thanks!
>           Javier.
> --
> Javier Pimás
> Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110608/b5e8ee4a/attachment.htm

More information about the Vm-dev mailing list