#7662: Improve GC of mutable objects -----------------------------+---------------------------------------------- Reporter: ezyang | Owner: Type: feature request | Status: new Priority: normal | Component: Runtime System Version: 7.7 | Keywords: Os: Unknown/Multiple | Architecture: Unknown/Multiple Failure: None/Unknown | Blockedby: Blocking: | Related: -----------------------------+---------------------------------------------- Haskell is a purely functional language at its core, but it can be also used for workloads involving mutation; it is for these workloads that our GC can be pretty poorly tuned (historically, we’ve fixed these issues case-by-case when they were causing problems for users, e.g. #650). Fortunately, the question of generational garbage collection in the face of lots of mutability is a well-studied one (c.f. the JVM) so this bug asks whether or not we can systematically appropriate any of the machinery developed here for GHC. Some ideas include: * Utilizing card marking at the page level for write barriers, instead of our current mutable lists, * Separating mutable and immutable (and lazy) data on the heaps, to make the previous scheme more likely to work well, * Organizing our generations in different pages, so that checking the generation of any object is as simple as a pointer comparison, * Figure out if we can do better than permanently keeping all mutable arrays permanently on the mutable list (which is really killer when you have lots of tiny mutable arrays), * More mutable closure types to remove the indirection that would normally result from an IORef (actually, you can UNPACK these, and I’m not 100% what happens in that case; it depends on how MutVar#s are represented) There’s probably more things but this is just a start to get things rolling. Test cases and benchmarks also appreciated! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7662 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler