Re: [GHC] #13110: GHC API allocates memory which is never GC'd

17 Apr 2017

      #13110: GHC API allocates memory which is never GC'd
-------------------------------------+-------------------------------------
        Reporter:  DanielG           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  GHC API           |              Version:  8.0.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by DanielG):

 I used to think it's the `FastString` table too because some initial
 profiling
 data pointed to retainers being in `FastString.<CAF>`. After some
 experimentation I dropped that hypothesis because 1) the memory consuption
 didn't change when I cleared the table and 2) the retainers actually
 disappeared
 from the profile after I made some changes (the details of which I do not
 recall) to the testcase to yield the current version. See also
 https://github.com/DanielG/ghc-mod/issues/834#issuecomment-271056632. FYI
 I
 patched GHC to export `string_table` and just re-initialized it before
 going
 into the loop. See the attached modified test case
 `LeakyResetStringTable.hs`.

 I'm not quite sure where this 20M number is coming from. My memory usage
 observations are based on [1] and [2] for all inclusive memory usage and
 Haskell heap only usage respectively.

 [1]:
 {{{
 echo $(( $(ps -eo size,pid,user,command --sort -size | grep Leaky | head
 -n1 | cut -d " " -f 1) / 1024 ))
 }}}

 [2]:
 {{{
 echo $(( $(pmap $(pgrep Leaky) | grep 200000000 | tr -s ' ' | cut -d ' '
 -f 2 | sed 's/K$//') / 1024 ))
 }}}

 As far as `rts_performMajorGC` goes I tried that of course which is why
 included
 it as a comment in the testcase. I just wasn't sure if it was actually
 necessary
 especially since I could reproduce the same memory usage with and
 without it. Thanks for clarifying that though.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13110#comment:7
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler