"John M McIntosh" <johnmci at ibm.net> wrote:
> 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!
> 


Everybody's talking about "some Smalltalks", but in fact Squeak supports
tricks like this.  With Squeak's finalization, whet you get the
"finalize" method, the original object has already been GC'd and is
gone!  However, the receiver of the finalize method is usually a #clone
of the original object, so it all works okay.  If you desire, you can
have the clone put itself back into use somewhere, and maybe set itself
up for finalization again (makin a clone of the clone).


So here's a trick that might help along the original poster.  Suppose
you have a glyph G.  Create a  wrapper WG which has a reference to G,
and pass out WG to clients.  Keep a hard reference to G, but a weak
reference to WG.  Now, when WG gets GC'd and finalized, you know that
the G itself is no longer in use, but you still have a reference to G to
do what you like with.  Now you can do things like maintain separate
"in-use" and "recently-in-use" collections.

The only thing missing from this scheme is that if Squeak runs out of
space, there's no mechanism for you to be able to free up some cached
glyphs.  Some people mentioned tying into lowSpaceWatcher; it seems that
the system could benefit by giving lowSpaceWatcher a rigistry of objects
to ask for more space, whenever space gets low.  Short of that, one
could always manually stick something in #lowSpaceWatcher to try and
free up font glyphs before doing anything else.

Well, one other thing is missing from this convoluted scheme: clarity. 
I pity the poor soul who ever has to figure out what all this stuff is
doing.  Worse will be if they try to make it work in a Smalltalk.  Oh
well.  If problems were to line themselves up and be easy to deal with,
they wouldn't be called problems :)


Lex