<br><br><div class="gmail_quote">On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel <span dir="ltr"><<a href="mailto:klaus.witzel@cobss.com">klaus.witzel@cobss.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Fri, 17 Jul 2009 22:13:33 +0200, Ralph Boland wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br>
Hi Ralph,<br>
<br>
when I saw this the first time, it seemed that the methods without *become* in their name, would do a #become: but they did not.</blockquote><div><br></div><div>at:put: and the like _do_ cause a become: if and when they invoke fullCheck and fullCheck determines the dictionary must grow.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Even if somebody tried with aMethod #become:, sooner or later the .image would crash: #becom:ing methods that can be in use by the VM is always a very bad idea. </blockquote>
<div><br></div><div>Um, no. Method dictionaries are only in use by the VM in message sends and then only if the method being looked up is not found in the method cache, which is typically < 3% of actually looked-up sends. In these situations a become: can't happen, and out of these situations, becaue method dictionaries are not in use, doing becomes on them cannot harm the VM. There is therefore no danger of using become: on method dictionaries.</div>
<div><br></div><div>In fact, it is *not* using become: which can the bad idea. Consider trying to add a method to a method dictionary, which involves at least two writes, that of the selector and that of the method, and many more if the dictionary has to be rehashed. Doing this in place must be done very carefully to avoid potentially crashing the VM. Consider writing the selector before the method, which might result in the Vm trying to run nil as the method if the selector was sent during this process. It is hence prudent to create a new dictionary and then either become: it (as the current squeak code does) or assign it to the methodDict inst var (as does e.g. VisualWorks). Using become: is simpler because it means that adding/removing/rehashing can be done independently of the class; the method dictionary merely becomes the new one. Assigning requires the class to create the copy and assign it to itself. But become: is a lot slower because the become: primitive has to traverse the entire heap looking for the (likely) single reference to it from the class whose method dictionary it is.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">So it rather looks like the methods you listed are 100% pure[tm] rot or crap.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have no idea if any of the Squeak forks exhibit the same behavior.<br>
</blockquote>
<br>
I suggest to remove them or, if you feel inclined, to deprecate them.<br>
<br>
/Klaus<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am running Squeak 3.10.2.<br>
<br>
Ralph Boland<br>
<br>
<br>
</blockquote>
<br>
<br>
</blockquote></div><br>