#7275: Give more detailed information about PINNED data in a heap profile -------------------------------------+------------------------------------ Reporter: edsko | Owner: Type: feature request | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.6.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Changes (by igloo): * owner: igloo => Comment: Simon and I discussed this a while ago. Here's his summary of where we ended up: ---- I think what we want to do is basically mark-sweep on the BF_PINNED blocks when profiling (only). The main question is how to represent the mark bit: I think just using the low-order bit of the info pointer should be fine, since that's what we use for ordinary forwarding pointers too. Specifically: - in evacuate_large, if the block is BF_PINNED, mark the object by setting the low-order bit of its info table. (PROFILING only) - after the GC is finished, sweep all the BF_PINNED blocks that we touched, which can be found by traversing the scavenged_large_objects list of each generation. For each BF_PINNED block, walk through the memory zeroing out any unmarked ARR_WORDS objects, and unmarking the marked objects. - in allocatePinned, zero out any slop caused by alignment constraints. Then I believe the pinned memory can be traversed correctly by the heap profiler with no further changes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7275#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler