[squeak-dev] References to a removed and reloaded class

Levente Uzonyi leves at elte.hu
Thu Sep 20 20:45:03 UTC 2012


On Thu, 20 Sep 2012, Colin Putney wrote:

> On Thu, Sep 20, 2012 at 11:28 AM, Levente Uzonyi <leves at elte.hu> wrote:
>
>> In order to fix this bug, I came up with two ideas:
>> 1) Recompile all methods which point to the old class when the class is
>> removed. This helps, because the class will be undeclared at that point, so
>> a new binding will be stored in Undeclared and the same binding will be used
>> when the class is added again. The drawback of this solution is that it only
>> fixes references in methods and it's slow, since it has to scan all methods
>> in the system.
>
> Couldn't we just move the existing binding to Undeclared? That might
> be unnecessary if there are no references, but I don't think it would
> hurt.

I tried that, but ran into another issue related to Undeclared. Class >> 
#rename: checks if the new class name is included in Undeclared. And if it 
is, it'll #inform: about it. The problem is that Undeclared holds a 
strong reference to its bindings, so if we remove a class which has no 
references and we move it to Undeclared, then it will linger there, until 
someone calls #cleanOutUndeclared. This is the weakness I described in 
solution #2.

To work around this we can remove the unreferenced keys from Undeclared 
in Class >> #rename:, but it means, that all methods in the system will 
be scanned for each renamed class.

>
>> 2) Create a new object (a datastructure) which points to the binding weakly
>> and provides fast lookup by class name. Store the binding in this object
>> when the class is removed and when a class is added, then check this object
>> for existing bindings (besides Undeclared). This solution is fast, but more
>> complicated than the previous one. But the same kind of
>> datastructure can be used to replace Undeclared, so it will not hold onto
>> bindings unnecessarily and it won't have to be cleared manually.
>>
>> I uploaded a few days ago System-ul.497.mcz to the Inbox which provides
>> solution #1. There are ways to improve the performance of SystemNavigation
>>>>
>>>> #allCallsOn: by ~20%, so it will take only 20-40ms more to remove a
>>
>> class from the system, which might be good enough for now.
>>
>> In 4.5 I'd like to implement solution #2 and replace Undeclared to work this
>> way too, but I think for 4.4 we can live with solution #1. What do you
>> think?
>
> I'm not sure I follow solution #2, but we'll be addressing this stuff

The idea is to store className -> binding pairs in a modified 
WeakValueDictionary which cleans itself automatically as its values get 
garbage collected or in a new kind of weak dictionary which has weak 
references to both its keys and values.

> anyway in 4.5 with Environments. We can certainly make sure this
> doesn't crop up again.

I guess there will be a per environment "Undeclared", but it shouldn't 
work like the current one (see above why).

I also saw, that Environment uses an IdentityDictionary to hold the 
classes instead of a SystemDictionary. It means that it doesn't use 
Undeclared at all and it doesn't use the hash advantage implemented in 
SystemDictionary, which uses #== and #hash (instead of #identityHash). 
Using #hash works, because Symbols are unique. Since calculating the 
hash is supported by a primitive, therefore it's pretty fast and the use 
of #hash itself reduces the chance for collisions.


Levente

>
> Colin
>
>


More information about the Squeak-dev mailing list