Rich Fought wrote:
I'm still chasing down a memory leak in my server application written in
Haskell using GHC 6.4.x under MinGW/MSYS. In the scenario described
below, I am repeating the same server request once per second continuously.
After utilizing some memory monitoring tools I've discovered that memory
usage fluctuates within in a range of approximately 850 KB (I assume as
garbage is collected),
What tool(s) did you use to obtain this figure?
but at regular intervals the range gets bumped up
by ~ 1 MB. So in effect I get a stair-stepping of memory usage that
keeps repeating until memory runs out. WinDbg has revealed that this
stepping coincides with the GHC runtime function getMBlocks().
>
My question is: what conditions affect when the runtime determines that
it needs more memory? Is it a pure "no more room" trigger or is there
some sort of algorithm behind it?
The block allocation layer grabs another Mb whenever it runs out, that's all.
The vast majority of the blocks in use by the storage manager will be either
free or assigned to the heap, so the most likely possibility is that you do have
a space leak (although that disagrees with the 850Kb figure you gave above).
I assume that this behavior means I still have a space leak somewhere in
my Haskell code, though none of leak check tools I utilize indicate such.
Did you try GHC's heap profiler?
Or simply running your program with +RTS -Sstderr will give you a clue about the
shape of the heap usage - each line is a single GC, and it includes the amount
of live data at that point.
If your program has a flat heap profile and yet is still grabbing more memory,
then something else is going on.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
