[GHC] #7662: Improve GC of mutable objects

GHC cvs-ghc at haskell.org
Tue Feb 5 11:14:47 CET 2013


#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



More information about the ghc-tickets mailing list