On 7 mai 05, at 19:59, John M McIntosh wrote:

> A technical question first thing in the morning before coffee.
>
> Ok, remember that collections you allocate do point to nil, so you can  
> have zillions of slots pointing to nil, also all instance vars are nil  
> at allocation time, so the comment about wanting to have less pointers  
> to nil is bogus.

Thanks because this was always what I was thinking.

> Also if you become many many slots to this new object  "String new"  
> there is a danger that most of these will be in OldSpace, the object  
> created will be in NewSpace and then we need to add many entries to  
> the remember table that remembers oldspace to newspace references so  
> that a newspace GC can happen.  This then:
>
> a) slows the newspace GC, which needs to be very fast, because it must  
> then scan many more roots via the remember table. In Squeak this is a  
> bad thing because we
> do not remember slots, rather we only remember the referencing object  
> and then hunt for the slot in question.
>
> b) Wanting to grown the remember table by a million objects can cause  
> problems depending the smalltalk implementation. For VW earlier  
> versions would give up and die.
> Current versions attempt much harder to avoid this sudden death.  
> Squeak will handle this condition by forcing a full GC when the root  
> table becomes mostly full.
>
> I did not look at VW, but assume the above should hold true.
>
> Now there might be some confusion here with twoway becomes versus one  
> way becomes. In some implementations if the smalltalk swaps pointers  
> doing foo become: nil would
> be interesting for a few seconds... Why some smalltalk pick one over  
> the other solution is because of performance/implementation issues  
> thus become: String new is viewed as a safe choice since you might not  
> know or understand the implementation when you invoke the cmd. See  
> become: and becomeForward: in Squeak and the become test Sunit.
>
>
> Still this means something is now pointing to a String new, versus nil  
> and might have interesting side-effects, such as pehaps the holder  
> checks for object foo, or nil, but sees non-nil so sends message to  
> String new.
>
>
>  As mentioned in the original note the intent is to use forward become  
> to remover references to obsolete classes. The optimal solution really  
> would be to find out who is holding
> onto the obsolete classes and clean those references up using methods  
> that remove the references, versus sticking nil in the slot without   
> understanding.
>
> Hint, usually using become oneway to nil to zap instances of domain  
> objects you can't figure out how to dispose of will bit you early in  
> the morning at year end close of business.

Thanks john.
I like this answer. I was always never really satisfied with this  
String new.
Good coffee :)
Stef

> On May 7, 2005, at 7:13 AM, stéphane ducasse wrote:
>
>> Hi john
>>
>> I was wondering if the squeak gc consider nil as any object or as a  
>> special object?
>> My question is related to the following email I sent:
>> In essence I was not sure that having multiple pointers was a  
>> problems.
>> Could you let me know?
>>
>> Stef
>>
>>
>> Hi brent
>>
>> I'm not sure but in VW it is advised to do
>>
>> 	i become: String new    and not i become: nil
>>
>> The point explained to me was that  else you will have a lot of  
>> pointer pointing to nil while you would prefer to have them pointing  
>> on fresh objects that will be garbagecollected.
>>
>> I do not know if this makes sense at all. Since lot of pointers are  
>> already pointing to nil
>> and gc may treat nil differently.
>>
>> Stef
>>
>>
>>
> --
> ======================================================================= 
> ====
> John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ======================================================================= 
> ====
>
>