[GHC] #14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at prompt

[GHC]

#14789: GHCi fails to garbage collect declaration `l = length [1..10^8]` entered at
prompt
-------------------------------------+-------------------------------------
           Reporter:  kabuhr         |             Owner:  (none)
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  GHCi           |           Version:  8.2.2
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Runtime
  Unknown/Multiple                   |  performance bug
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 This was recently reported on Stack Overflow
 (https://stackoverflow.com/questions/48723119/binding-len-length-xs-and-
 then-calculating-len-causes-ghc-to-consume-lots).

 With GHC 8.2.2, assigning the length of a large list as a top-level
 declaration at the GHCi prompt and evaluating it:

 {{{
 Prelude> l = length [1..10^8]
 Prelude> l
 10000000
 Prelude>
 }}}

 allocates about 7 gigs of memory before displaying a result, and then
 memory continues to grow over the next few seconds (at the idle GHCi
 prompt) until 10 gigs of memory has been allocated.  None of it is freed
 until the interpreter session ends.

 In contrast, directly evaluating the expression or assigning it with a
 let-statement does **not** exhibit this behavior:

 {{{
 Prelude> length [1..10^8]
 10000000
 Prelude> let l = length [1..10^8]
 Prelude> l
 10000000
 Prelude>
 }}}

 Also, loading the top-level declaration from a file and then evaluating it
 at the prompt does **not** exhibit the problem.

 I took a look at Ticket [ticket: 14336] and applied the `-fno-it` patch
 referenced there.  This slightly changed the pattern of memory usage: it
 grew to about 4 gigs before displaying the result, but then continued to
 grow for several seconds at the GHCi prompt before landing at about 10
 gigs.

 I verified that the bug still exists on the current "master" branch
 (though I didn't check the "ghc-8.4" branch).

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