Opened 4 years ago

Last modified 4 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: Other Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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 (12)

comment:1 Changed 4 years ago by igloo

difficulty: Unknown
Milestone: 7.8.1
Owner: set to igloo

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

Milestone: 7.8.37.10.1

Moving to 7.10.1

comment:4 Changed 3 years ago by Lemming

Cc: ghc@… added

comment:5 Changed 2 years ago by thoughtpolice

Milestone: 7.10.17.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 18 months ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:7 Changed 17 months ago by thomie

Component: CompilerProfiling

Also reported as #10455.

comment:8 Changed 17 months 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 17 months ago by bgamari

Component: CompilerProfiling

comment:10 Changed 15 months ago by maoe

Cc: maoe added

comment:11 Changed 13 months ago by thomie

Milestone: 8.0.1

comment:12 Changed 4 months ago by George

Type of failure: None/UnknownOther

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

Note: See TracTickets for help on using tickets.