Expiring cached data?

[Conal Elliott]

Cool idea!  Still, this discussion suggests to me the idea of
"relatively weak pointers".  Instead of a pointer being either strong or
weak, what if it could have a strength attribute (estimated value to the
app), e.g., in the real interval of zero to one?  The garbage collector
would prefer breaking weaker pointers over stronger ones.  The strength
required to survive a GC would depend on available memory and on the
distribution of existing pointer strengths and the reclamation benefits
of breaking weaker ones.

     - Conal

-----Original Message-----
From: haskell-bounces at haskell.org [mailto:haskell-bounces at haskell.org]
On Behalf Of Tom Pledger
Sent: Monday, November 03, 2003 12:18 PM
To: haskell at haskell.org
Subject: RE: Expiring cached data?

Conal Elliott writes:
 | Hi Andrew.  This situation is what weak pointers [1] are for.  You
keep
 | weak rather than regular pointers to your cache data.  The garbage
 | collector clears out the weak pointers and reclaims cache data when
 | necessary.  However, I don't think there is any policy to make
 | discriminating choices about *which* cache data gets discarded, for
 | instance least recently (or frequently) used.
 :

How about adapting splay trees so that their pointers become weak
after a certain depth?  The advantage for caching is that the more
frequently used elements move closer to the root, so you wouldn't have
to add much code for tracking recent use, just a depth threshold.

See the book Purely Functional Data Structures for more details on
implementing splay trees in a functional setting.

- Tom

_______________________________________________
Haskell mailing list
Haskell at haskell.org
http://www.haskell.org/mailman/listinfo/haskell