Hello Simon, Thursday, May 7, 2009, 2:04:05 PM, you wrote:
I've heard it's hard to contain a long-running Haskell application in a finite amount of memory
not exactly. you may alloc fixed pool of memory to application (say, 1gb) if you know that it never need more memory. but as far as you don't do it, memory usage grows with each major GC. ghc just don't provide any way to return memory to OS (there is a ticket on it, you can add yourself to CC list to vote for its resolution)
But let's be clear: this is not a memory leak, the issue is only that GHC's runtime retains as much memory as was required by the program's high-water-mark memory usage. Fixing this will never reduce the high-water-mark. So I'm not sure what you meant by "memory usage grows with each major GC".
1. none said that it's memory leak, at least in haskell code 2. it seems that one of us doesn't know intimate details of GHC GC :) the following is my understanding, learned from +RTS -s/-S listings with ghc 6.4 or so: copying GC: let's imagine that we perform major GC when 100 mb is allocated, of those 10 mb are live. doing GC, ghc will alloc 10+ mb from OS, and promote 100 mb freed to allocation area. so from this point program will occupy 110mb of memory (although only 10 mb is really used ATM) next major GC will occur when all these 100 mb will be allocated, i.e. overall memory allocated will be 110 mb. again, GHC will allocate as much memory as required for live data, increasing program footprint compacting GC: if major GC occurs when 100 mb is allocated, GHC increase memory footprint 2x (controlled by +RTS -F), and then perform GC. or it will perform GC and only then alloc more memory? i don't remember Simon, it will be VERY USEFUL if GC description that says about these behaviors will be added to manual. i'm definitely not the authoritative source on this topic and it seems that even you forget some details as time goes. this topic is very important for large programs and this question regularly arises here. we need authoritative description that pays attention to all GC-related RTS switches -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com