Ah, a GC issue. First dealing with 100K objects will happen really
quickly on machines today. If you had 10 million, then a different
story.
The Squeak VM does not use reference counting, I'll refer you to
http://minnow.cc.gatech.edu/squeak/1469
and
http://www.smalltalkconsulting.com/papers/GCPaper/GCTalk%202001.htm
In your case once the 100K object is tenured, the cost is non-existent
 unless
a full GC occurs. When it's disposed of, the mark phase, which is
looking for live objects
it won't count/visit/see the 'dead' 100K objects. The sweep phase will
 note they are dead, but
sweeping is much faster than marking and will take only a few ms or
less.
Once the objects are tenured then when they are collected depends
because that requires a full GC which are rare or forced events. If
the  objects still are in new space then they'll be collected in most
likely  a few ms in
a busy system.
Shouldn't see  any hicups.
I'll note there is some interesting issues with performance if a very
large collection in oldspace
gets tagged as being a root of the world (one or more elements
referring back to new space), because of how the root's of the world
are handled in Squeak. Someday we should fix that. It shows up as
Squeak running much faster
after you do a full GC event after allocating and populating a very
large collection. At this point I would do an explicit full GC after
doing the populate of your 100K collection to see if this is an issue.
PS Weak references are non-optimal, the GC logic is for the most part
quite tuned C code, excluding the case of weak reference logic since
we  expect only to find a few of them...  Others are welcome to dig
around  the GC algorithms and propose faster logic.  Having a 100K
weak  references would be an interesting test, could be something
might  choke...
On Tuesday, September 30, 2003, at 12:32  PM, Martin Drautzburg wrote:
> Suppose I have a tree of objects. Each object maintains a collection
> of children and each child holds a reference to its parent. The root
> node is kept in a class variable. Let there be 100,000 objects.
>
> If I chop off the root node then 100,000 objects will have to be
> garbage collected. I would assume that this will take a lot of time
> doesn't it.
>
> When will that happen ? At any time ?
> Will it make my application seem to hang ?
>
> Is the parent pointer a bad idea because this way no object will ever
> have a refence cound of zero or is reference counting not used at
> all?
>
> Would it be better to use weak references somewhere ?

It might take a while; 100,000 objects will likely cover a good bit of
memory. It might well also have caused quite a few of the nodes to be
moved into 'old' space, depending on a lot of factors like how long the
tree lived etc.
>
> When will that happen ? At any time ?
Incremental gcs happen when various things occur; a large number of
objects have been allocated, time has passed, various prims are called.
Full gcs happen more rarely and take longer.
> Will it make my application seem to hang ?
Probably for a short while - and if you are on a machine using virtual
memory and it thrashes it could seem a long time.
Experiment. Make your tree and delete the root inside a MessageTally
spyOn:. It is possible to alter some of the gc parameters using the
primitiveVMParameter message. I've not heard anyone mention much use of
that capability and any results it might provide.
>
> Is the parent pointer a bad idea because this way no object will ever
> have a refence cound of zero or is reference counting not used at
> all?
No reference counting used in Squeak. You might find some useful
information in my chapter of the nublue book  (Squeak: Open Personal
Computing and Multimedia, also available online at
http://coweb.cc.gatech.edu/squeakbook/ )
>
> Would it be better to use weak references somewhere ?
I doubt it in this case!
tim