On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel <klaus.witzel at cobss.com>wrote:

> On Fri, 17 Jul 2009 22:13:33 +0200, Ralph Boland wrote:
>
>  MethodDictionary has a method    "growNoBecome".
>> It is invoked by  "MethodDictionary>>fullCheckNoBecome".
>> It is invoked by  "MethodDictionary>>at:putNoBecome:".
>> It is invoked by ?????  (that is nobody).
>>
>> Can anybody explain this or should I generate a bug report?
>>
>
> Hi Ralph,
>
> 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.


at:put: and the like _do_ cause a become: if and when they invoke fullCheck
and fullCheck determines the dictionary must grow.

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.


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.

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.



> So it rather looks like the methods you listed are 100% pure[tm] rot or
> crap.
>
>  I have no idea if any of the Squeak forks exhibit the same behavior.
>>
>
> I suggest to remove them or, if you feel inclined, to deprecate them.
>
> /Klaus
>
>  I am running Squeak 3.10.2.
>>
>> Ralph Boland
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090718/9f833a64/attachment.htm