[squeak-dev] unused methods in methodDictionary

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.

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.

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

2009/7/18 Eliot Miranda <[hidden email]>:

>
>
> On Fri, Jul 17, 2009 at 11:10 PM, Klaus D. Witzel <[hidden email]>
> 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.

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

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.

/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