#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): Replying to [comment:7 simonpj]:
Great work. There is definitely a space leak here and it should not be to hard to find. Some ideas
* In `CoreLint.lintSingleBinding` you'll find a series of tests. If you comment then out one by one, you'll find when the space leak comes back. That test must be forcing the offending bit of `IdInfo`.
I commented out `lintIdUnfolding` and then the leak came back with `-dcore-lint` enabled.
* Does the leak happen when you use `-dshow-passes`? That shows the size of eac intermediate, and `exprSize` is deliberately strict (see `CoreStats.bndrSize`).
I've been using `-v`, which I think shows the same information, and it doesn't eliminate the leak.
You could try making `CoreSeq.megaSeqidInfo` actually force the unfolding info (currently commented out) and see if that helps. (I'm not sure WHY it is commented out, incidentally.)
Instead I defined a new version of `seqUnfolding`, based on `lintIdUnfolding`, and added it to `megaSeqIdInfo`: {{{#!hs miniSeqUnfolding :: Unfolding -> () miniSeqUnfolding (CoreUnfolding { uf_tmpl = e, uf_src = src }) | isStableSource src = seqExpr e miniSeqUnfolding (DFunUnfolding { df_con = con, df_bndrs = bndrs , df_args = args }) = seqExprs args miniSeqUnfolding _ = () }}} This was enough to make the leak go away, even without using `-dcore- lint`. Both the `CoreUnfolding` and `DFunUnfolding` cases are needed to make the leak go away; or perhaps there are two leaks. (Without the `isStableSource` guard, the runtime exploded.) So there are thunks in the expressions inside unfoldings which, I believe, point to old versions of the Core program. I'm going to continue invesigating but I'm out of time for today. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13426#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler