Re: [Haskell-cafe] space leak with 'concat' ?
Note that only monomorphic declarations are CAFed. If you have an explicit polymorphic signature, it will be treated as a function and garbage-collected as usual. So if you have, e.g., a list of Doubles, declaring it as foo :: Num a => [a] would do the trick. Cheers, S. On Tue, Jan 27, 2009 at 6:22 PM, Jake McArthur wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Henning Thielemann wrote: > | in that module I defined the text to be printed as top-level > | variable which might have been the problem. But this can't be the > | problem of the compiled version of the program, where I encountered the > | leak. So I have to keep on searching that leak. > > You have created a constant applicative form (commonly abbreviated CAF). > GHC assumes that all top level declarations are constants, and simply > does not garbage collect them. In the case of infinite structures, this > can be a bad thing. This *does* affect even compiled code. > > The best way to avoid the problem, of course, is to avoid having > infinite constants at the top level. Assuming that is impossible, your > solution seems acceptable to me. Somebody more knowledgeable or creative > than I may be able to come up with something nicer, though. > > - - Jake > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkl/lz0ACgkQye5hVyvIUKl0JgCgx5ddBc0Y44+ghFakr7Mex1RP > zfUAnjh9BDI5+A9tEnaox20DbXbipX33 > =2MCw > -END PGP SIGNATURE- > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] space leak with 'concat' ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Henning Thielemann wrote: | in that module I defined the text to be printed as top-level | variable which might have been the problem. But this can't be the | problem of the compiled version of the program, where I encountered the | leak. So I have to keep on searching that leak. You have created a constant applicative form (commonly abbreviated CAF). GHC assumes that all top level declarations are constants, and simply does not garbage collect them. In the case of infinite structures, this can be a bad thing. This *does* affect even compiled code. The best way to avoid the problem, of course, is to avoid having infinite constants at the top level. Assuming that is impossible, your solution seems acceptable to me. Somebody more knowledgeable or creative than I may be able to come up with something nicer, though. - - Jake -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkl/lz0ACgkQye5hVyvIUKl0JgCgx5ddBc0Y44+ghFakr7Mex1RP zfUAnjh9BDI5+A9tEnaox20DbXbipX33 =2MCw -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] space leak with 'concat' ?
On Tue, 27 Jan 2009, Henning Thielemann wrote: On Tue, 27 Jan 2009, Jonathan Cast wrote: To show that there's nothing wrong with concat per se, try this version instead: ghc +RTS -M16m -c30 -RTS -e 'print $ concat $ repeat "bla"' This should print forever without any problems. You are right, this works. My example was extracted from a larger module. But in that module I defined the text to be printed as top-level variable which might have been the problem. But this can't be the problem of the compiled version of the program, where I encountered the leak. So I have to keep on searching that leak. Yes, the top-level variables seem to be the leak. I had to turn them into functions with dummy arguments _and_ attach INLINE pragmas to them in order to keep GHC away from buffering their content. Is there a less ugly way to achieve this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] space leak with 'concat' ?
On Tue, 27 Jan 2009, Jonathan Cast wrote: To show that there's nothing wrong with concat per se, try this version instead: ghc +RTS -M16m -c30 -RTS -e 'print $ concat $ repeat "bla"' This should print forever without any problems. You are right, this works. My example was extracted from a larger module. But in that module I defined the text to be printed as top-level variable which might have been the problem. But this can't be the problem of the compiled version of the program, where I encountered the leak. So I have to keep on searching that leak. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] space leak with 'concat' ?
On Tue, 2009-01-27 at 22:12 +0100, Henning Thielemann wrote: > $ ghc +RTS -M16m -c30 -RTS -e 'concat $ repeat "bla"' > > This breaks down after a while, also if I increase the memory restriction: > > ... > ablablablablablablablablablablablablablablablablablablablablablaHeap > exhausted; > Current maximum heap size is 15998976 bytes (15 Mb); > use `+RTS -M' to increase it. > > > Whereas this one works: > > $ ghc +RTS -M16m -c30 -RTS -e 'cycle "bla"' > 'concat' seems to be the culprit. What's so bad about it? cycle builds a circular list: cycle xn = let ys = xn ++ ys in ys which concat isn't smart enough to do (obviously). That's not an issue normally, since the list is being consumed in a properly lazy fashion. But it looks like, for some reason, ghc -e is holding a pointer to the entire expression-to-evaluate in this case, so cons cells that have already been printed don't get garbage collected. To show that there's nothing wrong with concat per se, try this version instead: ghc +RTS -M16m -c30 -RTS -e 'print $ concat $ repeat "bla"' This should print forever without any problems. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] space leak with 'concat' ?
$ ghc +RTS -M16m -c30 -RTS -e 'concat $ repeat "bla"' This breaks down after a while, also if I increase the memory restriction: ... ablablablablablablablablablablablablablablablablablablablablablaHeap exhausted; Current maximum heap size is 15998976 bytes (15 Mb); use `+RTS -M' to increase it. Whereas this one works: $ ghc +RTS -M16m -c30 -RTS -e 'cycle "bla"' 'concat' seems to be the culprit. What's so bad about it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
