Reference counting

John.Maloney at disney.com John.Maloney at disney.com
Wed Oct 27 18:56:55 UTC 1999


Hi, John:

So what's your conclusion about weak references from these
experiences? What do you think of Squeak's implementation of them,
which avoids some of the problems you mention below?

To address the original issue, which is how to manage
an in-memory cache of objects such as pre-rendered glyphs
from a large Asian character set: I would update a timestamp
each time a particular glyph was requested. When the cache
got too large, I'd remove the least recently used glphs
from the cache. If the glpyh has no other references, it
will be garbage collected. (I might invoke a full GC
after cleaning up the cache to force the space to be
reclaimed immediately.)

If I really didn't want to remove a glyph from the cache if
it had references, I'd use "Smalltalk pointersTo: theGlyph"
to find out if it had any references. This operation is
expensive, but one could write (in Squeak!) a bulk version
that counts the references to a bunch of objects (i.e.,
all the cache entries) in parallel for greater efficiency.

But I really wouldn't bother with the latter. If need be,
one can quickly find any extant instances of glpyhs
that have be removed from the cache but are still in
memory. One could use this technique to recover a
glyph that was removed from the cache while it was still
referenced in case it was requested again.

Note that these techniques don't use weak references
at all, since you want to keep the heavily used objects
in the cache even when they have no other references.

Hope this helps...

	-- John


At 11:11 PM -0700 10/26/99, John M McIntosh wrote:
>I'll also chip in and say you can find lots more on GC theory at my site, in
>papers and presentations.
>
>As pointed out one of the strange things that one can do in some flavors of
>Smalltalk is take back an about to be GCed object. As part of finalization
>you can make a strong reference and effectively forbid the GCing of the
>object. Mind you it makes my head hurt why you would want to do this!
>
>Regarding Latency, an example. Given this simplified code
>
>thing isAnOrange ifTrue: [Transcript show: thing color]
>
>Many times I've seen a walkback, nil does not understand color, but what
>happened, how could thing which just responded to the isAnOrange message
>become nil? Well a GC occur and thing just well disappeared.
>
>A few years back if I recall I believe VisualAge 2.x only finalized one
>object per GC pass. Create a few thousand weak objects and GC them, then
>this took a long time. If you were dependent on having the finalization
>occur shortly after the object was destroyed, then you were in for a
>surprise.





More information about the Squeak-dev mailing list