[GHC] #9314: Huge space leak of GHC API 7.8.x

[GHC]

#9314: Huge space leak of GHC API 7.8.x
-------------------------------------+-------------------------------------
              Reporter:  kazu-       |            Owner:
  yamamoto                           |           Status:  new
                  Type:  bug         |        Milestone:  7.8.4
              Priority:  high        |          Version:  7.8.3
             Component:  GHC API     |         Keywords:
            Resolution:              |     Architecture:  Unknown/Multiple
      Operating System:              |       Difficulty:  Unknown
  Unknown/Multiple                   |       Blocked By:
       Type of failure:  Other       |  Related Tickets:
             Test Case:              |
              Blocking:              |
Differential Revisions:              |
-------------------------------------+-------------------------------------

Comment (by rwbarton):

 OK here's the situation. Kazu's program is statically linked against the
 GHC API (ghc builds statically-linked executables by default) which means
 GHC is loading the static library versions of ghc-prim, integer-gmp, base.
 This was the case in GHC 7.6 also, but that version shipped with .o files
 (e.g. HSghc-prim-0.3.0.0.o) which the GHC linker can read as a single
 unit. These are not included with GHC 7.8 on platforms that use dynamic
 libraries by default (I guess since GHCi would not use them), so GHC 7.8
 has to read the .a files instead. As described in a comment in
 `loadArchive()`, for reasons having to do with alignment, each member
 object file of an archive is loaded  into its own mmap()ed page(s). The
 base package consists of approximately a zillion tiny object files (split
 objects), each of which costs 4 kilobytes, so as the comment mentions,
 this is quite wasteful. Almost all of the memory mapped by the program
 under 7.8 is attributable to either these mappings or to the executable
 file itself.

 We could perhaps come up with a more efficient scheme for loading archive
 files, but a workaround is to just build the executable with `-dynamic`,
 so that it will load the GHC API as a shared library and avoid this
 excessive allocation.

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