Reference counting

John Duncan jddst19+ at pitt.edu
Tue Oct 26 18:01:24 UTC 1999


> Is that right?  I was under the impression that the object
> isn't purged until the gc occurs. [Indeed, what is
> described is something more like reference counting than
> gc].  Further, can't you register objects for finalization,
> thus giving each object a chance to say "I want to stay?"
> or to copy itself somewhere -- or would that action be
> beyond the scope of a valid finalization action?

The GC occurs in short, high-frequency bursts so that it's not a dog
on response time. So, the effect of GC is almost immediate. But, if
you imagine my example, you'll see that there are response-time
benefits for not having to rerender the glyphs very often, so normal
GC doesn't seem like the best way. Nor does traditional caching,
because the data have properties that reflect temporal locality, and
traditional caching will have a higher miss rate than some sort of
more intelligent method. The best cache is a 1-1 correspondence
between cache locations and references to be used before the program
switches to a different locale. This is the goal that I'm shooting
for, but I'm trying to figure out where to start. I began prototyping,
but then I came to this reference counting idea, and I think it has
potential.

Finalization isn't about asking objects to politely leave the party,
it's collecting the coat and hat and tossing them all out the door.
So, I'm not sure that it's a good practice to copy the object. First
of all, if the object will ever be finalized again, then it can't be
copied to a strong pointer. But, if copied weakly, it will be caught
next GC. This could get expensive.

Instead, we want more or less strong objects that simply don't care if
they are replaced when someone more important comes along. Or, in my
book, dictionaries that will put new objects in slots held by unused
objects, avoiding rehash and space munching.

I looked at the flyweight pattern. Why is it that the patterns book
seems so useless? It discusses structure clearly, but not behavior too
well. Does Wirth need to come out with a book: "Structure + Behaviors
= Patterns"?

:)

-John.





More information about the Squeak-dev mailing list