[GHC] #4029: ghci leaks memory when loading a file

[GHC]

#4029: ghci leaks memory when loading a file
-------------------------------------+-------------------------------------
        Reporter:  blarsen           |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  ⊥
       Component:  GHCi              |              Version:
      Resolution:                    |             Keywords:  memory leak
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by jme):

 There is a new leak on the 8.0 branch.  For example, running
 attachment:leak.script, which
 simply loads attachment:Leak.hs 20 times, results in a max residency
 of 115 MB:

 {{{
 $ inplace/bin/ghc-stage2 --version
 The Glorious Glasgow Haskell Compilation System, version 8.0.0.20160206
 $ inplace/bin/ghc-stage2 --interactive +RTS -t < leak.script > /dev/null
 <<ghc: 2104620200 bytes, 311 GCs, 26012178/114880456 avg/max bytes
 residency (11 samples), 236M in use, 0.002 INIT (0.002 elapsed), 1.869 MUT
 (1.882 elapsed), 1.425 GC (
 1.424 elapsed) :ghc>>
 }}}

 This is an obvious regression from 7.10.3, for which the max
 residency is 18.3 MB:

 {{{
 $ ghc --version
 The Glorious Glasgow Haskell Compilation System, version 7.10.3
 $ ghc --interactive +RTS -t < leak.script > /dev/null
 <<ghc: 1757780832 bytes, 461 GCs, 11400611/18318760 avg/max bytes
 residency (16 samples), 48M in use, 0.002 INIT (0.002 elapsed), 1.362 MUT
 (1.367 elapsed), 1.150 GC (1.
 149 elapsed) :ghc>>
 }}}

 There is a quick fix for the bulk of the leak (just make the `hsc_IC`
 field in `HscTypes.HscEnv` strict), but I'd like to track down what
 caused the regression before I submit a patch.  In the meantime, anyone
 who needs a workaround (without recompiling) should periodically run a
 command which references the contents of the loaded module.  For
 example, by querying the type of a constructor after each load,
 attachment:workaround.script is able to reduce the max residency to
 29.1 MB:

 {{{
 $ inplace/bin/ghc-stage2 --interactive +RTS -t < workaround.script >
 /dev/null
 <<ghc: 2106120848 bytes, 422 GCs, 16580354/29127088 avg/max bytes
 residency (14 samples), 80M in use, 0.002 INIT (0.002 elapsed), 1.862 MUT
 (1.875 elapsed), 1.363 GC (1.
 363 elapsed) :ghc>>
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4029#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler