There were a number of leaks causing previously loaded modules to be
retained after a new :load. This fixes enough leaks to get the
tests to pass from D4658.
- rGHC Glasgow Haskell Compiler
- ghci-leak (branched from master)
Lint Warnings Excuse: no Severity Location Code Message Warning compiler/main/HscTypes.hs:1247 TXT3 Line Too Long
No Unit Test Coverage
- Build Status
Buildable 20720 Build 45811: [GHC] Linux/amd64: Continuous Integration Build 45810: [GHC] OSX/amd64: Continuous Integration Build 45809: [GHC] Windows/amd64: Continuous Integration Build 45808: arc lint + arc unit
I'll admit I'm a bit unclear as to why precisely this set of fields must be banged. Was this set arrived at empirically or is there are a deeper reason why the others can't be problematic that I am missing?
It's impossible to explain why this set of fields needs to be strict, because the rationale is of the form "the field points to a thunk from line N of TcRnDriver.hs which refers to a thunk from line Y of HscTypes.hs which refers to the HscEnv". To find these I used gdb with the findPtr() utility in rts/Printer.c. Retainer profiling is supposed to solve this kind of problem but in practice it doesn't.
So, while scattering some strict fields around clearly isn't ideal, it could be worse.
An alternative would be to do what we do in the Core-to-core passes and deeseq the whole thing, but this is a complex set of datatypes and writing manual seq functions for all of them would be a pain, not to mention the overhead of traversing everything.
I wanted to check the impact on compiler perf, so full nofib results: P180 (ignore the runtime results, I think my laptop was busy doing other things during one of the runs)
Bottom line: compiler allocations +0.1%, I think that's OK. It had an adverse effect on one of the compiler perf tests (T13701, +13% allocs) but I think that test is non-idiomatic in that it generates a lot of modules with no content, so it was probably benefiting from some of the lazily evaluated things that were made strict here. The time to run the test wasn't measurably different after this diff.
@ezyang @simonpj I'd like your thoughts here. Hopefully it's clear from the comment above what I'm trying to achieve - this space leak is a complete show-stopper for us and I need to fix it somehow, but the fix here breaks a few Backbpack tests, e.g. see build results B45428. I think the reason is (please correct me if I'm wrong):
Any ideas on how we can modify this fix so that it doesn't break Backpack? Thoughts I had:
I'm pretty unfamiliar with the Backpack implementation so I'd really appreciate any pointers you have. Thanks!