Opened 7 years ago

Last modified 11 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: newcomer Cc: ghc@…, maoe
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Other 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 (15)

comment:1 Changed 7 years ago by igloo

difficulty: Unknown
Milestone: 7.8.1
Owner: set to igloo

comment:2 Changed 6 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 6 years ago by thoughtpolice


Moving to 7.10.1

comment:4 Changed 5 years ago by Lemming

Cc: ghc@… added

comment:5 Changed 5 years ago by thoughtpolice


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 4 years ago by thoughtpolice


Milestone renamed

comment:7 Changed 4 years ago by thomie

Component: CompilerProfiling

Also reported as #10455.

comment:8 Changed 4 years ago by bgamari

Component: ProfilingCompiler

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 4 years ago by bgamari

Component: CompilerProfiling

comment:10 Changed 4 years ago by maoe

Cc: maoe added

comment:11 Changed 4 years ago by thomie

Milestone: 8.0.1

comment:12 Changed 3 years ago by George

Type of failure: None/UnknownOther

The current behaviour is not very informative. This would be nice to fix.

comment:13 Changed 3 years ago by varosi

Is there a chance that issue to enter GHC 8.2?

comment:14 in reply to:  13 Changed 3 years ago by dfeuer

Replying to varosi:

Is there a chance that issue to enter GHC 8.2?

8.2 has already branched, so I don't think there is any chance of that.

comment:15 Changed 11 months ago by mpickering

Keywords: newcomer added

Would be very useful to implement this and there is a clear implementation plan indicated by Ian in comment:2.

Note: See TracTickets for help on using tickets.