[GHC] #13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC 8.2

[GHC]

#13426: compile-time memory-usage regression for DynFlags between GHC 8.0 and GHC
8.2
-------------------------------------+-------------------------------------
        Reporter:  hvr               |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  high              |            Milestone:  8.2.1
       Component:  Compiler          |              Version:  8.1
      Resolution:                    |             Keywords:
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 rwbarton):

 I now suspect this leak doesn't really have anything to do with unfoldings
 in particular. It just shows up that way as a result of the fact that the
 evaluation of `coreBindsSize` in the simplifier loop forces most parts of
 the Core program, but does not force unfoldings (as mentioned in
 comment:7). It seems that the simplifier repeatedly traverses these stable
 `Core` and `DFun` unfoldings but there is some part of the new unfolding
 that the next simplifier iteration does not look at that retains a
 reference to the old version of the program.

 I also suspect that the evaluation of `coreBindsSize` in the simplifier
 loop should be unnecessary if there weren't space leaks in the simplifier,
 and if we got rid of it we would see this space leak not just in
 unfoldings but everywhere, and possibly in more programs, which might make
 it easier to track down.

 I spent a lot of time using some RTS functions to dump heap
 representations and in particular to look for thunks and (using DWARF
 information) find where they were coming from. But it turned out not to be
 a good approach because of how the simplifier is structured. Basically,
 the output of each simplifier iteration contains a large number of thunks,
 of which most (but apparently not all) will be forced by the next
 simplifier iteration, and replaced by a large number of new thunks. I
 don't know how to find only the thunks that aren't getting forced by this
 process.

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