<br><br><div class="gmail_quote">On Sat, Jul 18, 2009 at 12:16 PM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/7/18 Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>>:<br>
<div><div></div><div class="h5">><br>
><br>
> On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel <<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>><br>
> wrote:<br>
>><br>
>> On Fri, 17 Jul 2009 22:13:33 +0200, Ralph Boland wrote:<br>
>><br>
>>> MethodDictionary has a method "growNoBecome".<br>
>>> It is invoked by "MethodDictionary>>fullCheckNoBecome".<br>
>>> It is invoked by "MethodDictionary>>at:putNoBecome:".<br>
>>> It is invoked by ????? (that is nobody).<br>
>>><br>
>>> Can anybody explain this or should I generate a bug report?<br>
>><br>
>> Hi Ralph,<br>
>><br>
>> when I saw this the first time, it seemed that the methods without<br>
>> *become* in their name, would do a #become: but they did not.<br>
><br>
> at:put: and the like _do_ cause a become: if and when they invoke fullCheck<br>
> and fullCheck determines the dictionary must grow.<br>
>><br>
>> Even if somebody tried with aMethod #become:, sooner or later the .image<br>
>> would crash: #becom:ing methods that can be in use by the VM is always a<br>
>> very bad idea.<br>
><br>
> Um, no. Method dictionaries are only in use by the VM in message sends and<br>
> then only if the method being looked up is not found in the method cache,<br>
> which is typically < 3% of actually looked-up sends. In these situations a<br>
> become: can't happen, and out of these situations, becaue method<br>
> dictionaries are not in use, doing becomes on them cannot harm the VM.<br>
> There is therefore no danger of using become: on method dictionaries.<br>
> In fact, it is *not* using become: which can the bad idea. Consider trying<br>
> to add a method to a method dictionary, which involves at least two writes,<br>
> that of the selector and that of the method, and many more if the dictionary<br>
> has to be rehashed. Doing this in place must be done very carefully to<br>
> avoid potentially crashing the VM. Consider writing the selector before the<br>
> method, which might result in the Vm trying to run nil as the method if the<br>
> selector was sent during this process. It is hence prudent to create a new<br>
> dictionary and then either become: it (as the current squeak code does) or<br>
> assign it to the methodDict inst var (as does e.g. VisualWorks). Using<br>
> become: is simpler because it means that adding/removing/rehashing can be<br>
> done independently of the class; the method dictionary merely becomes the<br>
> new one. Assigning requires the class to create the copy and assign it to<br>
> itself. But become: is a lot slower because the become: primitive has to<br>
> traverse the entire heap looking for the (likely) single reference to it<br>
> from the class whose method dictionary it is.<br>
><br>
<br>
</div></div>Isn't become get postponed till GC and just a forward table entry +<br>
marks the object as forwarded one?</blockquote><div><br></div><div>No. become: is an atomic primitive that sweeps object memory. There is an optimization where if all objects involved (become is built upon Array>>elementsExchangeIdentityWith:) are all new then only eden and the roots are scanned. But this is rarely the case for method dictionaries.</div>
<div><br></div><div>Your idea looks cute but in fact simply amortises the cost because many dereferences in the VM have to check for forwarding, and that's slower in the long run because becomes are rare.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<div><div></div><div class="h5"><br>
>><br>
>> So it rather looks like the methods you listed are 100% pure[tm] rot or<br>
>> crap.<br>
>><br>
>>> I have no idea if any of the Squeak forks exhibit the same behavior.<br>
>><br>
>> I suggest to remove them or, if you feel inclined, to deprecate them.<br>
>><br>
>> /Klaus<br>
>><br>
>>> I am running Squeak 3.10.2.<br>
>>><br>
>>> Ralph Boland<br>
>>><br>
>>><br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Best regards,<br>
Igor Stasenko AKA sig.<br>
<br>
</font></blockquote></div><br>