[GHC] #7662: Improve GC of mutable objects

[GHC]

#7662: Improve GC of mutable objects
---------------------------------+------------------------------------------
    Reporter:  ezyang            |       Owner:                  
        Type:  feature request   |      Status:  new             
    Priority:  normal            |   Milestone:  _|_             
   Component:  Runtime System    |     Version:  7.7             
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  None/Unknown    
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown
  * milestone:  => _|_


Comment:

 One problem with card marking is that you need to be able to traverse the
 heap linearly to scan the objects in a card.  GHC's heap doesn't support
 this, because we have gaps between objects left behind when a thunk is
 overwritten by an indirection.  It's possible to fill in the gaps (we do
 this when `DEBUG` is enabled), but it's a fair bit of overhead on every
 update.  This is why we only have card marking for arrays.

 We should have a small array type that uses the same write barrier as a
 `MutVar#`, i.e. it isn't on the mutable list until it is modified, and
 there's no card marking.  This would help in the `unordered-containers`
 package I believe.

 I've often wondered whether we can fully unpack an `IORef`, that is have a
 mutable pointer field in an ordinary constructor.  It would be nice if we
 could do it, but I fear it is hard to achieve - you can't re-box a mutable
 field like you can with an immutable field.  Perhaps we could represent a
 `MutVar#` as a pointer plus an offset instead.

 (I'm leaving the milestone for this at _|_, which is not to say that none
 of this will ever happen, just that we don't have concrete plans right
 now).

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