[squeak-dev] Re: unused methods in methodDictionary
Eliot Miranda
eliot.miranda at gmail.com
Sat Jul 18 21:10:57 UTC 2009
On Sat, Jul 18, 2009 at 1:23 PM, Klaus D. Witzel <klaus.witzel at cobss.com>wrote:
> On Sat, 18 Jul 2009 21:06:57 +0200, Eliot Miranda wrote:
>
> On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel 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.
>>
>
> Uhm, oh, see below.
>
> 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.
>>>
>>
> 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) ?
OK, I wasn't sure. I thought you were still talking about method
dictionaries. Apologies.
> 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.
>>
>
> NP. You write about aMethodDictionary (and I agree with that :) , and I
> wrote about aCompiledMethod.
OK, then +1 :)
>
>
> /Klaus
>
>
> 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/a46bbb1a/attachment.htm
More information about the Squeak-dev
mailing list
|