[GHC] #7831: Bad fragmentation when allocating many large objects

#7831: Bad fragmentation when allocating many large objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Consider our good old friend, the space-leaky list program: {{{ import Control.Exception import System.Environment f n = let xs = [1..n] in sum xs * product xs main = do [n] <- getArgs evaluate (f (read n :: Integer)) }}} It is not surprising that this program is quite the memory guzzler; what is surprising is how much GHC *wastes* when evaluating this program: {{{ Fragmentation, wanted 95 blocks, 105 MB free }}} (For reference, a block is 4k, so 95 blocks is a measly 380k!) The magnitude of the problem can be seen in this graphic: [[Image(http://web.mit.edu/~ezyang/Public/fragmentation-ghc.png)]] (The x-axis takes advantage of the fact that the number of requested blocks increases ~linearly over time, since we keep multiplying the integer which adds a constant number of extra bytes to the representation; unused free memory corresponds to blocks of free memory in GHC's free list, which it is holding onto from the OS but not using to store user data.) When the requested allocations are *just* large enough (just slightly over half a megablock, or 128 blocks), we start allocating a megablock per allocation and waste half of the megablock, since none of the leftovers are ever large enough to store any of the later allocations. Can we do anything about this? One possibility is to occasionally check how much space we're losing to fragmentation, and everyone once in a while pay the cost of copying tenured large objects and pack them together in a megablock group (obviously one wants to avoid doing this too often, since copying large objects is expensive!) I'm open to better suggestions though! (Apologies if this is a duplicate; I didn't see any open tickets with the word "fragmentation" in them). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7831 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7831: Bad fragmentation when allocating many large objects ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 7.8.1 -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7831#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7831: Bad fragmentation when allocating many large objects ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by PHO): * cc: pho@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7831#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7831: Bad fragmentation when allocating many large objects ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Changes (by refold): * cc: the.dead.shall.rise@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7831#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#7831: Bad fragmentation when allocating many large objects ---------------------------------+------------------------------------------ Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.7 Keywords: | Os: Unknown/Multiple Architecture: Unknown/Multiple | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: | Blocking: Related: | ---------------------------------+------------------------------------------ Comment(by josef): Over ten years ago we ran into a similar problem with the ocaml garbage collector. Below a link to the reply we got from Damien Doligez, the ocaml gc guru. Hopefully it can contribute in some way to resolving this issue. http://caml.inria.fr/pub/ml-archives/caml- list/2003/01/e8ee9d44073ff9cb7d257fef86bc8f53.en.html Just my 2 cents. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7831#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC