[GHC] #15665: Break up the stable pointer table

[GHC]

#15665: Break up the stable pointer table
-------------------------------------+-------------------------------------
        Reporter:  dfeuer            |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #7670             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by dfeuer):

 One challenge is that the active entry list for a generation could jump
 all over the heap, making major GC more expensive than it is now when the
 table is well populated. Is there a sufficiently cheap way to ameliorate
 this? I believe there is. The trick is to have one active entry list per
 generation in each block, and an active block list in each generation. So
 now GC for a generation will always finish one block before it moves to
 the next, which I imagine should be much easier on the caches. We just
 need to reserve room for as many pointers in each block as there are GC
 generations, which doesn't look like too high a price to me.

 Can we improve concurrency, which was really what got me started thinking
 about this machine? I don't really know. The easiest thing would be to
 divide everything strictly among the capabilities. Each capability would
 have its own free list and its own active lists. Each block would be owned
 by just one capability. Only that capability would be permitted to
 allocate stable pointers in that block, though others could mark pointers
 for deletion. The trouble with that rigidity is that one capability could
 have loads of entries on its free list while another is flat broke and
 forced to allocate fresh blocks (for example, a heavy `StablePtr`
 allocator could migrate from one capability to another). Is there some
 sufficiently cheap way to tax the rich to feed the poor without too much
 bureaucracy? I don't see any, but I'm surely no expert.

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