> 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.)
>

This is good, but if you look on the web for LRU and VM you'll find lots of
material discussion how to determine which VM  page should go out and hope
that it's not needed in the near future, avoiding page thrashing. This of
course is very similar to the problem you are solving.

John Maloney mentioned LRU, there is FIFO (first in, first out) Keep an
linked list of glyphs, when you access one move it to the head of the list.
On memory shortage take glyphs off the tail of the list. This could be
faster I'm not sure about the suggestion about creating all those timestamp
objects, also you'd need to inspect all the glyphs to find the oldest.

However for LRU there are algorithms to attempt LRU but minimize work
effort.




--
===========================================================================
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================
Custom Macintosh programming & various Smalltalk dialects
PGP Key: DSS/Diff/46FC3BE6
Fingerprint=B22F 7D67 92B7 5D52 72D7  E94A EE69 2D21 46FC 3BE6
===========================================================================