What are you trying to use this for? It seems to me that for memo tables you almost never have references to they keys outside the lookup table since the keys are usually computed right at the last minute, and then discarded (otherwise it might be easier to just cache stuff outside the function). <br>
<br>For example with a naive fibs, the values you are passing in are computed, and probably don't exist before you do the recursive call, and then are discarded shortly afterward.<br><br>It seems like putting a cap on the cache size, and then just overwriting old entries would be better.<br>
Am I missing something?<br><br>- Job<br><br><br><br><div class="gmail_quote">On Wed, Sep 16, 2009 at 4:48 PM, Rodney Price <span dir="ltr"><<a href="mailto:rodprice@raytheon.com">rodprice@raytheon.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">How does garbage collection work in an example like the one below? You<br>
memoize a function with some sort of lookup table, which stores function<br>
arguments as keys and function results as values. As long as the<br>
function remains in scope, the keys in the lookup table remain in<br>
memory, which means that the keys themselves always remain reachable<br>
and they cannot be garbage collected. Right?<br>
<br>
So what do you do in the case where you know that, after some period of<br>
time, some entries in the lookup table will never be accessed? That is,<br>
there are no references to the keys for some entries remaining, except<br>
for the references in the lookup table itself. You'd like to allow the<br>
memory occupied by the keys to be garbage collected. Otherwise, if the<br>
function stays around for a long time, the size of the lookup table<br>
always grows. How do you avoid the space leak?<br>
<br>
I notice that there is a function in Data.IORef,<br>
<br>
mkWeakIORef :: IORef a -> IO () -> IO (Weak (IORef a))<br>
<br>
which looks promising. In the code below, however, there's only one<br>
IORef, so either the entire table gets garbage collected or none of it<br>
does.<br>
<br>
I've been reading the paper "Stretching the storage manager: weak<br>
pointers and stable names in Haskell," which seems to answer my<br>
question. When I attempt to run the memoization code in the paper on<br>
the simple fib example, I find that -- apparently due to lazy<br>
evaluation -- no new entries are entered into the lookup table, and<br>
therefore no lookups are ever successful!<br>
<br>
So apparently there is some interaction between lazy evaluation and<br>
garbage collection that I don't understand. My head hurts. Is it<br>
necessary to make the table lookup operation strict? Or is it<br>
something entirely different that I am missing?<br>
<br>
-Rod<br>
<br>
<br>
On Thu, 10 Sep 2009 18:33:47 -0700<br>
Ryan Ingram <<a href="mailto:ryani.spam@gmail.com">ryani.spam@gmail.com</a>> wrote:<br>
<br>
><br>
> memoIO :: Ord a => (a -> b) -> IO (a -> IO b)<br>
> memoIO f = do<br>
> cache <- newIORef M.empty<br>
> return $ \x -> do<br>
> m <- readIORef cache<br>
> case M.lookup x m of<br>
> Just y -> return y<br>
> Nothing -> do let res = f x<br>
> writeIORef cache $ M.insert x res m<br>
> return res<br>
><br>
> memo :: Ord a => (a -> b) -> (a -> b)<br>
> memo f = unsafePerformIO $ do<br>
> fmemo <- memoIO f<br>
> return (unsafePerformIO . fmemo)<br>
><br>
> I don't think there is any valid transformation that breaks this,<br>
> since the compiler can't lift anything through unsafePerformIO. Am I<br>
> mistaken?<br>
><br>
> -- ryan<br>
<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</blockquote></div><br>