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