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. Doing so would seem to be
an interesting and useful extension. Regards,
- Conal
[1] Stretching the storage manager: weak pointers and stable names in
Haskell, Simon Peyton Jones, Simon Marlow, and Conal Elliott. Proc
Workshop on Implementing Functional Languages, 1999.
http://research.microsoft.com/~simonpj/Papers/weak.htm
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of andrew cooke
Sent: Sunday, November 02, 2003 5:59 PM
To: [EMAIL PROTECTED]
Subject: Expiring cached data?
I have a Haskell program that caches data in a tree. Unfortunately, the
tree grows to exceed the available memory over time. In a different
language, where I might be handling the caching myself, rather than
relying on laziness within the language, I might work round this by
keeping track of which leaves in the tree were more recently used, and,
when memory run slow, deleting those that have not been used for some
time
(by the nature of the problem, access to particular caches tend to be
grouped, so a long-unused cache can be deleted without much performance
penalty).
What options do I have in Haskell? I'm interested both in general
solutions (maybe some compilers do this anyway?) and in approaches to
structuring the program so that I can control caching in more detail.
Thanks,
Andrew
--
http://www.acooke.org/andrew
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
