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.

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.

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