<br><br><div class="gmail_quote">On Sat, Jul 18, 2009 at 1:23 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 Sat, 18 Jul 2009 21:06:57 +0200, Eliot Miranda wrote:<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel wrote:<br>
<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>
MethodDictionary has a method "growNoBecome".<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
</blockquote>
<br>
Hi Ralph,<br>
<br>
when I saw this the first time, it seemed that the methods without *become*<br>
in their name, would do a #become: but they did not.<br>
</blockquote>
<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>
</blockquote>
<br></div>
Uhm, oh, see below.<div class="im"><br>
<br>
<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<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
would crash: #becom:ing methods that can be in use by the VM is always a<br>
very bad idea.<br>
</blockquote></blockquote>
<br></div>
My (aMethod become: ...) can also be read (aCompiledMethod become: ...). Would you say this has the potential to crash the .image, if for example, one returns (or so, perhaps even in another Process) ?</blockquote><div><br>
</div><div>OK, I wasn't sure. I thought you were still talking about method dictionaries. Apologies.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
In fact, it is *not* using become: which can the bad idea.<br>
</blockquote>
<br></div>
NP. You write about aMethodDictionary (and I agree with that :) , and I wrote about aCompiledMethod.</blockquote><div><br></div><div>OK, then +1 :) </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br><font color="#888888">
<br>
/Klaus</font><div><div></div><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br>
<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<br>
crap.<br>
<br>
I have no idea if any of the Squeak forks exhibit the same behavior.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ralph Boland<br>
<br>
</blockquote>
<br>
</blockquote></blockquote>
<br>
<br>
</div></div></blockquote></div><br>