[squeak-dev] Class>>binding broken (was: Re: The Trunk: CollectionsTests-ar.138.mcz)

Igor Stasenko siguctua at gmail.com
Wed Feb 3 06:25:47 UTC 2010


On 2 February 2010 19:47, Andreas Raab <andreas.raab at gmx.de> wrote:
> Levente Uzonyi wrote:
>>
>> After updating my image, most tests in ReadStreamTest fails or raises an
>> error. If I open a Monticello Browser, select CollectionTests and Trunk,
>> click changes, I see lots of methods changed. So this is probably a new MC
>> issue. Loading the .mcz from the Trunk solves the problem.
>
> This is an interesting issue that arises from the new traits implementation
> but its root cause is elsewhere. What happens is that when reshaping a class
> that uses traits it may "loose" it's local methods due to Class>>binding
> being just plain wrong. When reshaping a class, a new class is created in
> which the methods get compiled but due to the incorrect usage of
> Class>>binding these newly compiled method will bind to the old class.
>
> The only reason this works at all is that at the end of the reshape we do a
> forward #become: which corrects this problem but the installation of the
> traits happens before the #become: has fixed them up.
>
> There are two possible solutions: Fix Class>>binding to test whether the
> association actually points to the class. This is straightforward but has a
> major disadvantage - it means that when adding ivars and stuff we will
> create new bindings for every method. Effectively that makes the class
> binding unsharable unless one adds another .
>
> The alternative is to defer the installation of traits until *after* the
> reshape is complete. This is not exactly trivial either but it would avoid
> the issue raised above.
>
> Opinions? Other alternatives?
>

- a compiled method's methodClass should always point to a class
object, which owns a method dict where that method installed to. There
should be no excuses in what shape a class object currently are (like
transition from old class shape to a new one),
because assignment of wrong methodClass could lead to fatal error(s) in VM.

So, i assume that current implementation is incorrect, because it
installs a method and violates that rule.
Please, no deferring, because it causing more problems (leads to more
complex code as well as putting extra responsibility on tools, which
loading the code to take care of this issue).

> Cheers,
>  - Andreas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list