[Haskell-cafe] following up on space leak

[Uwe Hollerbach]

On 7/5/09, Paul L <ninegua at gmail.com> wrote:
> Previously you had lastOrNil taking m [a] as input, presumably
> generated by mapM. So mapM is actually building an entire list before
> it returns the argument for you to call lastOrNil. This is where you
> had unexpected memory behavior.
>
> Now you are "fusing" lastOrNil and mapM together, and instead of
> building a list, you traverse it and perform monadic action along the
> way. This can happen in a constant memory if the original pure list is
> generated lazily.
>
> I think the real problem you had was a mis-understanding of mapM, and
> there was nothing wrong with your previous lastOrNil function. mapM
> will only return a list after all monadic actions are performed, and
> in doing so, it inevitably has to build the entire list along the way.
>
> --
> Regards,
> Paul Liu
>
> Yale Haskell Group
> http://www.haskell.org/yale

Hi, Paul, thanks for the comments. You're quite right that I am fusing
the two functions together, but I think I wasn't mis-understanding
mapM... I knew I was generating the entire list, and aside from the
slight inefficiency of generating it only to tear it down an instant
later, that would have been no problem. But I was expecting all of the
memory associated with the list to be reclaimed after I had processed
it, and that was what was not happening as far as I could tell. (This
isn't one monolithic list, by the way; it's the small bodies of a
couple of small scheme functions that get evaluated over and over. So
the setup and teardown happens a lot.) I don't have very good
intuition yet about what should get garbage-collected and what should
get kept in such situations, and in fact I'm kind of in the same boat
again: the test case now runs much better, but it still leaks memory,
and I am again stumped as to why. Could I see something useful by
examining ghc core? I haven't looked at that yet, no idea what to look
for...

Uwe