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<div>
<br></div><div><div>0x78c68dd4: 0x779cadf5 0x1848038d 0x00000003 0x78c68e64</div><div>0x78c68de4: 0x77831004 0x77831004 0x77831004 0x77831004</div><div>0x78c68df4: 0x77831004 0x77831004 0x77831004 0x77831004</div>
<div>0x78c68e04: 0x77831004 0x77831004 0x77831004 0x77831004</div><div>0x78c68e14: 0x77831004 0x77831004 0x77831004 0x77831004</div><div>0x78c68e24: 0x77831004 0x77831004 0x77831004 0x77831004</div>
<div>0x78c68e34: 0x77831004 0x77831004 0x77831004 0x77831004</div><div>0x78c68e44: 0x77831004 0x77831004 0x77831004 0x77831004</div><div>0x78c68e54: 0x77831004 0x77831004 0x77831004 0x778cb5d4</div>
<div>0x78c68e64: 0x00da3287 0x77831004 0x77831004 0x77831004</div><div><br></div><div>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?</div>
<div><br></div><div>Thanks!</div><div> Javier.</div><meta http-equiv="content-type" content="text/html; charset=utf-8"><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 2:01 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <br><br><br><div class="gmail_quote">On Wed, Jun 8, 2011 at 8:35 AM, Javier Pimás <span dir="ltr"><<a href="mailto:elpochodelagente@gmail.com" target="_blank">elpochodelagente@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Hi, this is another simple (I hope) question:<div><br></div><div>I have an instance of MethodDictionary, which is defined as</div><div><br></div><div>Dictionary variableSubclass: #MethodDictionary<div><span style="white-space:pre-wrap"> </span>instanceVariableNames: ''</div>
<div><span style="white-space:pre-wrap"> </span>classVariableNames: ''</div><div><span style="white-space:pre-wrap"> </span>poolDictionaries: ''</div><div><span style="white-space:pre-wrap"> </span>category: 'Kernel-Methods'</div>
<div><br></div><div>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?</div>
</div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>HTH</div><div>Eliot</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<div><br></div><div>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?</div><div><br></div><div>Thanks!</div><div>
Javier.</div><br>-- <br>Javier Pimás<br>Ciudad de Buenos Aires<br>
</div>
<br></blockquote></div><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Javier Pimás<br>Ciudad de Buenos Aires<br>
</div>