Hi Ralph,<br><br><div class="gmail_quote">On Sun, Jul 19, 2009 at 10:17 PM, Ralph Boland <span dir="ltr"><<a href="mailto:rpboland@gmail.com">rpboland@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I have been looking at MethodDictionary.<br>
It seems to have very little to do with Methods.<br>
It seems to me that a better design would have been<br>
to have a class VarDictionary which does not use<br>
Associations (similar to MethodDictionary).<br>
MethodDictionary would inherit from VarDictionary<br>
and add the couple of additional methods it needs.<br>
VarDictionary would then be available for others to use.<br>
<br>
Better still would be to have MethodDictionary not<br>
be a variable class at all but simply use an additional<br>
variable "values". Again MethodDictionary should<br>
really inherit from a class that provides this service.<br>
I would use this service in my own code.<br>
<font color="#888888"><br>
Ralph Boland</font></blockquote><div><br></div><div>Actually I think the best representation for MethodDictionary is as a flat pair-wise sequence of selector and method, sorted by selector identityHash. </div><div><br></div>
<div>Advantages:</div><div><br></div><div>One saves significant space. There is one less object per method dictionary (no values array) and no empty space in the sequence. We shrank the image by about 8% when we did this for VisualWorks.</div>
<div><br></div><div>Small method dictionaries (say size <= 16 entries) are linearly scanned without needing to fetch the identityHash of the selector. This is faster for small dictionaries because the cost of three memory references in different places (selector's hash, dictionary's selector sequence, dictionary's method sequence) is higher on modern machines than the one scan of the dictionary's contents sequence.</div>
<div><br></div><div>nil looks ot the VM like an empty MethodDictionary so classes with no methods (there are quite a few) don't need a dictionary object at all.</div></div><br><div>Disadvantages:</div><div>Large dictionaries are looked up using binary search, which can be slower, because one has to fetch the hash of the selector being probed for to comp[are it with the message selector's hash. But this isn't the common case.</div>
<div><br></div><div>Dictionaries must be grown whenever a selector/method par is added or shrunk whenever one is removed, but this is rare (only happens when compiling a new method or removing an old) and can be e.g. batched if creating a new dictionary (e.g. if loading code form some binary stream).</div>
<div><br></div><div><br></div><div>Something we didn't yet do in VisualWorks is to make the identityHash of a Symbol dependent on its contents. If this is done then within images with the same hash width dictionaries will always have the same order because selectors will have the same hashes, which means loading binary code can be faster since the order of the dictionary on disc is the same as in memory.</div>
<div><br></div><div>I plan to implement the above when doing the new image format work later this year.</div><div><br></div><div>2¢</div><div><br></div><div>best</div><div>Eliot</div>