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

Javier Pimás elpochodelagente at gmail.com
Thu Jun 9 01:41:21 UTC 2011

thanks both mariano and you for the quick answers, they helped a lot. Now
let's get the hands dirty: I want to understand a bit better the internals
of this tiny animals. I have a MethodDictionary, with tally=1 and an array
of size 32, filled with all nils except for the last position. Looking at it
with gdb, including header I get

0x78c68dd4:     0x779cadf5      0x1848038d      0x00000003      0x78c68e64
0x78c68de4:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68df4:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e04:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e14:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e24:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e34:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e44:     0x77831004      0x77831004      0x77831004      0x77831004
0x78c68e54:     0x77831004      0x77831004      0x77831004      0x778cb5d4
0x78c68e64:     0x00da3287      0x77831004      0x77831004      0x77831004

where the second int (0x1848038d) is the base header (the oop points to
0x78c68dd8). The first fields is a smallint for 1, I guess. Now the
questions: in the header, size bits are 100011, why? Also second object
would be the array oop in case the object weren't flat, but in this case it
seems to point to the position past the last variable field, am I guessing
right? How does the VM manage this flattening of the instance vars?


On Wed, Jun 8, 2011 at 2:01 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:

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

Javier Pimás
Ciudad de Buenos Aires
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110608/100f9993/attachment.htm

More information about the Vm-dev mailing list