[squeak-dev] Re: unused methods in methodDictionary

Eliot Miranda eliot.miranda at gmail.com
Sat Jul 18 19:49:44 UTC 2009


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.


>
> >>
> >> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090718/d47a7b48/attachment.htm


More information about the Squeak-dev mailing list