#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