[GHC] #10915: Statistical profiling support in the RTS

[GHC]

#10915: Statistical profiling support in the RTS
-------------------------------------+-------------------------------------
        Reporter:  bgamari           |                Owner:  bgamari
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):  Phab:D1215,
                                     |  Phab:D1214
-------------------------------------+-------------------------------------
Description changed by bgamari:

Old description:

> Now since GHC can produce useful debugging information (e.g. DWARF
> annotations and source notes) in compiled objects, it would great if we
> could leverage this for more efficient profiling.
>
> While ideally we would be able to rely on external tools like `perf` for
> this task, this would require that the STG stack be walkable like a
> standard C stack.
>
> A more feasible alternative is to incorporate a simple statistical
> profiler into the RTS.

New description:

 Now since GHC can produce useful debugging information (e.g. DWARF
 annotations and source notes) in compiled objects, it would great if we
 could leverage this for more efficient profiling.

 While ideally we would be able to rely on external tools like `perf` for
 this task, this would require that the STG stack be walkable like a
 standard C stack.

 A more feasible alternative is to incorporate a simple statistical
 profiler into the RTS.

 Profiling is defined loosely here as the collection of information
 describing the current state of evaluation in response to certain
 triggers. In practice this will be the collection of the current symbol
 being evaluated triggered on a few events of interest,

  * Memory allocation
  * Periodic timers for time-based profiling
  * Blackhole blocking for locating performance problems due to sharing in
 parallel programs

--

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10915#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler