Opened 4 years ago

Last modified 8 months ago

#7275 new feature request

Give more detailed information about PINNED data in a heap profile

Reported by: edsko Owned by:
Priority: normal Milestone:
Component: Profiling Version: 7.6.1
Keywords: Cc: ghc@…, maoe
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


This is particularly useful when tracking down memory leaks due to retaining (sub)bytestrings which themselves retain larger bytestrings. At the moment, all the profile tells us is that this memory is "PINNED" but it doesn't give us any info at all as to where the memory was allocated.

Change History (11)

comment:1 Changed 4 years ago by igloo

  • difficulty set to Unknown
  • Milestone set to 7.8.1
  • Owner set to igloo

comment:2 Changed 3 years ago by igloo

  • Owner igloo deleted

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.

comment:3 Changed 2 years ago by thoughtpolice

  • Milestone changed from 7.8.3 to 7.10.1

Moving to 7.10.1

comment:4 Changed 2 years ago by Lemming

  • Cc ghc@… added

comment:5 Changed 22 months ago by thoughtpolice

  • Milestone changed from 7.10.1 to 7.12.1

Moving to 7.12.1 milestone; if you feel this is an error and should be addressed sooner, please move it back to the 7.10.1 milestone.

comment:6 Changed 13 months ago by thoughtpolice

  • Milestone changed from 7.12.1 to 8.0.1

Milestone renamed

comment:7 Changed 12 months ago by thomie

  • Component changed from Compiler to Profiling

Also reported as #10455.

comment:8 Changed 12 months ago by bgamari

  • Component changed from Profiling to Compiler

We discussed this during this week's GHC meeting. Simon Marlow confirmed that Ian's suggestion would likely be feasible given a few days of effort. There is, however, the possibility that we would need to be more careful about zeroing out slots that we might accidentally dereference.

comment:9 Changed 12 months ago by bgamari

  • Component changed from Compiler to Profiling

comment:10 Changed 10 months ago by maoe

  • Cc maoe added

comment:11 Changed 8 months ago by thomie

  • Milestone 8.0.1 deleted
Note: See TracTickets for help on using tickets.