#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