[GHC] #12848: Reduce long-term memory usage of GHCi

#12848: Reduce long-term memory usage of GHCi ---------------------------------------+-------------------------- Reporter: arybczak | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: x86_64 (amd64) | Type of failure: Other Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: ---------------------------------------+-------------------------- If you take moderately sized Haskell project (let's use lens as an example) and decide to work with it using `cabal repl`, memory usage of GHCi becomes a bit problematic after a few code reloads. I compared 7.10.3 and 8.0.1 using the following steps: 1. Start GHCi with `cabal repl`. 2. Wait for all modules to load, check memory usage with `htop`. 3. Issue `find . -name '*.hs' -exec touch {} +` in src directory. 4. Issue `:r` in GHCi so it reloads all modules. 5. Repeat (3) and (4) four more times. Results: '''GHC 7.10.3''' * After `cabal repl`: 874MB * After reloading all modules (1st): 1304MB * After reloading all modules (2nd): 1763MB * After reloading all modules (3rd): 2216MB * After reloading all modules (4th): 2672MB * After reloading all modules (5th): 3121MB Basically, every time modules are reloaded memory usage increases by ~450MB, which is definitely not fun. '''GHC 8.0.1''' * After `cabal repl`: 1322MB * After reloading all modules (1st): 2144MB * After reloading all modules (2nd): 2201MB * After reloading all modules (3rd): 2208MB * After reloading all modules (4th): 2212MB * After reloading all modules (5th): 2213MB Here the initial memory usage is much higher as with 7.10.3 and there is a sharp increase after first full reload, but then it more or less plateaus. I presume this change is the result of 6ae616f5be1db6da8bc0c5e36736a76cfea46844 - upfront memory usage is probably higher due to more things being forced (and the fact that memory usage doesn't increase indefinitely is great). However, I'm still concerned about the spike after the first reload - would it be possible to get rid of (or at least decrease) it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12848 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12848: Reduce long-term memory usage of GHCi ------------------------------------+-------------------------------------- Reporter: arybczak | Owner: (none) Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by saurabhnanda): I have proposed this as an idea for GSoC / HSoC at https://github.com /haskell-org/summer-of-haskell/pull/15/files If anyone is interesting in mentoring students working on fixing this space leak, please participate in the discussion at https://github.com /haskell-org/summer-of-haskell/issues/29 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12848#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12848: Reduce long-term memory usage of GHCi ------------------------------------+-------------------------------------- Reporter: arybczak | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by bgamari): * priority: normal => high Comment: Indeed 400MB is quite a jump. I think this would make for a reasonable SoC project if coupled with a few other bugs. I suspect tracking this down won't take an entire summer, even for a new contributor. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12848#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12848: Reduce long-term memory usage of GHCi ------------------------------------+-------------------------------------- Reporter: arybczak | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Comment (by saurabhnanda): Is https://simonmar.github.io/posts/2018-06-20-Finding-fixing-space- leaks.html related to this ticket? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12848#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12848: Reduce long-term memory usage of GHCi ------------------------------------+-------------------------------------- Reporter: arybczak | Owner: (none) Type: feature request | Status: new Priority: high | Milestone: Component: GHCi | Version: 8.0.1 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 (amd64) Type of failure: Other | Test Case: Blocked By: | Blocking: Related Tickets: #15111 | Differential Rev(s): Wiki Page: | ------------------------------------+-------------------------------------- Changes (by osa1): * related: => #15111 Comment: Indeed that is related, however I just tried GHC 8.6 and this problem still occurs. As in the original report for GHC 8.0.1, the leak stops after a few reloads. This seems very similar to #15111, I don't know why this is still not fixed. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12848#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC