2009/7/18 Eliot Miranda <eliot.miranda at gmail.com>:
>
>
> On Sat, Jul 18, 2009 at 12:16 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> 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?
>
> No.  become: is an atomic primitive that sweeps object memory.  There is an
> optimization where if all objects involved (become is built upon
> Array>>elementsExchangeIdentityWith:) are all new then only eden and the
> roots are scanned.  But this is rarely the case for method dictionaries.
> Your idea looks cute but in fact simply amortises the cost because many
> dereferences in the VM have to check for forwarding, and that's slower in
> the long run because becomes are rare.

ah, i thought about #becomeForward. And its not my idea , because
forwarding tables used in Squeak VM.
Yes, and this part, you are talking about - i.e. amotrisation is
unclear for me, how Squeak using it. From what i have seen, it avoids
the dereference checks somehow..
or maybe i didn't understood it completely :)

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



-- 
Best regards,
Igor Stasenko AKA sig.