#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