Opened 8 years ago

Last modified 14 months ago

#881 new feature request

Improve space profiling for references

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Profiling Version: 6.4.2
Keywords: Cc: pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

GHC's great space profiling tools don't appear to be much help when your
leaked memory is stored in references (IORefs, StablePtrs?, etc). I had
a real-life case where the allocation profile showed me where the leaked
data came from, and I could guess that it was being held by some
reference, but I couldn't tell which one. Retainer set profiling showed
a big suspicious entry for "SYSTEM", but I couldn't find any way to
pinpoint the problem. (It ended up being a missing freeStablePtr in
hsgnutls, found by code inspection.)

Here's a contrived example that just allocates a bunch of IORefs:

    import Control.Monad
    import Data.IORef

    main = repeatM (newIORef [1,2,3])
    repeatM io = liftM2 (:) io (repeatM io)

Retainer set profiling shows everything in "SYSTEM". None of the other
profiling methods say anything interesting either. What I'd like to
get, I think, is (1) your memory is being held in IORefs (2) allocated
by this cost center and (3) being retained by this cost center. I guess
I'm looking for something like a memory profiler for a traditional
language.

Andrew Pimlott

Simon Marlow comments: "The relevant predicate "is retainer" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly. Being able to tweak this, or maybe just install a better default would be an improvement.

Change History (9)

comment:1 Changed 7 years ago by igloo

  • Milestone set to 6.8

comment:2 Changed 6 years ago by simonmar

  • Milestone changed from 6.8 branch to _|_

No immediate plans to do anything about this.

comment:3 Changed 6 years ago by SamB

Isn't the problem here that the retainer profiling is stopping at the IORef and writing the memory off as retained by "SYSTEM", when it should go back and find out who retains the IORef?

comment:4 Changed 6 years ago by simonmar

  • Architecture changed from Unknown to Unknown/Multiple

comment:5 Changed 6 years ago by simonmar

  • Operating System changed from Unknown to Unknown/Multiple

comment:6 Changed 4 years ago by PHO

  • Cc pho@… added

comment:7 Changed 15 months ago by morabbin

  • Type of failure set to None/Unknown

Orphaned feature request?

comment:8 Changed 15 months ago by simonmar

I think this might be fixed, since MUT_VAR is considered a retainer, but it needs testing (don't have prof libs installed on my laptop and I'm on slow wifi right now).

comment:9 Changed 14 months ago by simonmar

The example still reports "SYSTEM", but I don't see an obvious reason why, so not closing this ticket.

Updated code:

{-# OPTIONS_GHC -fprof-auto #-}
import Control.Monad
import Data.IORef
import System.Environment

main = do
  [n] <- getArgs
  replicateM (read n) (newIORef [1,2,3])
$ ./881 10000000 +RTS -hr -K1g -S 
Note: See TracTickets for help on using tickets.