[GHC] #10812: High memory usage
GHC
ghc-devs at haskell.org
Sat Aug 29 18:18:43 UTC 2015
#10812: High memory usage
---------------------------------+-----------------------------------------
Reporter: danilo2 | Owner:
Type: bug | Status: new
Priority: high | Milestone:
Component: Compiler | Version: 7.10.2
Resolution: | Keywords:
Operating System: MacOS X | Architecture: x86_64 (amd64)
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Revisions:
---------------------------------+-----------------------------------------
Comment (by bgamari):
The problem is that the GC isn't being performed after traversing `xr`; if
you manually insert a `performGc` before the `threadDelay` then you will
find things behave as you expect.
For the record, the given test seems to behave as expected on my machine.
My testing methodology was rather crude,
{{{
$ ghc -O Test.hs; ./Test & pid=$!; while true; do cat /proc/$pid/stat >>
stat; sleep 0.01; done
$ ipython --pylab
>>> a = genfromtxt('stat')
>>> vsize = a[:,22] # see proc(5)
>>> plot(vsize / 1024**2)
>>> ylabel('vsize / megabytes')
>>> xlabel('something approximating time')
}}}
With `[1..10000000]` `vsize` peaked around 1.8GB around 3 seconds after
starting the process. With the testcase provided above `vsize` remained at
this peak for the remaining duration of the program. With a manual
`performGC` after the traversal, however, it dropped to essentially zero
around a second after plateauing. It stayed there for the rest of the
execution.
The moral of the story is if you want the runtime to GC at a given point,
you must tell it. GC occurs due to allocation. Given that there is
essentially no allocation after the traversal it isn't terribly surprising
that no GC is occurring.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10812#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list