#12455: Compact Regions -------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: task | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime System | Version: 8.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonmar: @@ -14,1 +14,1 @@ - rtsopts=-DS"` + rtsopts=-DS"` (I think this is the static object problem, see below) @@ -19,1 +19,7 @@ - * Improve comments + * Static Objects: currently compaction copies static objects into the + compact. This violates some invariants (_STATIC objects should not be on + the heap), but is important because we would otherwise have pointers from + compacts to static objects that would need to be followed during GC, in + order to find CAFs. I don't like this at all. + + And in general, improve the comments. New description: I'm going to use this task to keep track of what we still need to do around compact regions before 8.2.1, and so I have somewhere to hang diffs. Here's the current ToDo list: * compaction should be interruptible by GC, otherwise we block a multithreaded program while compacting (I know how to do this and have a prototype, just need to finish it). * Make it work with profiling * We should have an API that doesn't require specifying a size, just `compact :: NFData a => a -> IO (Compact a)` * libraries/compact/tests failures with `EXTRA_HC_OPTS="-debug -with- rtsopts=-DS"` (I think this is the static object problem, see below) * Do we need both `totalW` and `totalDataW`? It looks like one of them is redundant to me. * What happens if we try to compact something that refers to a large block? One larger than a megablock? * Static Objects: currently compaction copies static objects into the compact. This violates some invariants (_STATIC objects should not be on the heap), but is important because we would otherwise have pointers from compacts to static objects that would need to be followed during GC, in order to find CAFs. I don't like this at all. And in general, improve the comments. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12455#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler