2009/7/18 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> 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.
>

Isn't become get postponed till GC and just a forward table entry +
marks the object as forwarded one?

>>
>> 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
>>>
>>>
>>
>>
>
>
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.