[gclist] Finalizers & Reference counting.

[Charles Fiterman]

At 10:49 AM 8/27/2002 -0400, you wrote:
>Charles --
>
>I'm not sure about the structure of your argument here.  You sometime
>seem to be arguing from current practical concerns, as in:
>
> > Suppose you are GotRocks Inc and can have lots of processors and lots of
> > storage but you must finish 90% of transactions in 1 second and the 
> rest in
> > 10 seconds. Suppose you are looking at a back end database server.
> >
> > Now the costs of reference counting can be beaten by having more
> > processors. But the costs of collection are a huge lump right where it
> > hurts.

This means collection occurs all at one time. Concurrent collection 
generally changes this but there are always special situations where it 
doesn't. For example the mutator can go into a flurry of changes where it 
touches every page in the system and keeps the collector from ever finishing.


>Well, depending on your definition of "lots of storage" and "huge
>lump", certainly concurrent collection can help a lot.  For example,
>we see applications with 500 MB of live data, and GC pauses of about
>100 ms.  (On older hardware!)  This seems consistent with results from
>other concurrent GC implementations.

Those are the numbers I see but I'm hearing from people with Gigabytes of 
live data and they are having trouble. Algorithms that are healthy at one 
level get sick given another power of ten of data.


>I don't know what you mean by:
>
> > Collection can only be subdivided so far because of cross pointers.

Collection is divided by giving each processor an area to collect. If 
processor A finds a pointer to processor B's data it notifies processor B. 
At small sizes this works fine, as we scale up it breaks down. GC 
parallelizes quite well at one scale but not another.


.