This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update .
  1. 17 Sep, 2019 1 commit
    • Matthew Pickering's avatar
      eventlog: Add biographical and retainer profiling traces · ae4415b9
      Matthew Pickering authored
      This patch adds a new eventlog event which indicates the start of
      a biographical profiler sample. These are different to normal events as
      they also include the timestamp of when the census took place. This is
      because the LDV profiler only emits samples at the end of the run.
      
      Now all the different profiling modes emit consumable events to the
      eventlog.
      ae4415b9
  2. 14 Jul, 2019 1 commit
    • John Ericson's avatar
      Expunge #ifdef and #ifndef from the codebase · d7c6c471
      John Ericson authored
      These are unexploded minds as far as the linter is concerned. I don't
      want to hit in my MRs by mistake!
      
      I did this with `sed`, and then rolled back some changes in the docs,
      config.guess, and the linter itself.
      d7c6c471
  3. 07 Jun, 2019 1 commit
  4. 19 Nov, 2018 1 commit
  5. 14 Oct, 2018 1 commit
  6. 21 Aug, 2018 1 commit
  7. 27 Jul, 2018 1 commit
    • Mitsutoshi Aoe's avatar
      rts: Flush eventlog in hs_init_ghc (fixes #15440) · 7a3e1b25
      Mitsutoshi Aoe authored
      Without this change RTS typically doesn't flush some important
      events until the process terminates or it doesn't write them at
      all in case it terminates abnormally.
      
      Here is a list of such events:
      
      * EVENT_WALL_CLOCK_TIME
      * EVENT_OS_PROCESS_PID
      * EVENT_OS_PROCESS_PPID
      * EVENT_RTS_IDENTIFIER
      * EVENT_PROGRAM_ARGS
      * EVENT_PROGRAM_ENV
      7a3e1b25
  8. 11 Jul, 2017 1 commit
    • Douglas Wilson's avatar
      Fix Work Balance computation in RTS stats · 7c9e356d
      Douglas Wilson authored
      An additional stat is tracked per gc: par_balanced_copied This is the
      the number of bytes copied by each gc thread under the balanced lmit,
      which is simply (copied_bytes / num_gc_threads).  The stat is added to
      all the appropriate GC structures, so is visible in the eventlog and in
      GHC.Stats.
      
      A note is added explaining how work balance is computed.
      
      Remove some end of line whitespace
      
      Test Plan:
      ./validate
      experiment with the program attached to the ticket
      examine code changes carefully
      
      Reviewers: simonmar, austin, hvr, bgamari, erikd
      
      Reviewed By: simonmar
      
      Subscribers: Phyx, rwbarton, thomie
      
      GHC Trac Issues: #13830
      
      Differential Revision: https://phabricator.haskell.org/D3658
      7c9e356d
  9. 29 Apr, 2017 1 commit
  10. 15 Feb, 2017 1 commit
  11. 31 Jan, 2017 1 commit
    • alexbiehl's avatar
      Abstract over the way eventlogs are flushed · 4dfc6d1c
      alexbiehl authored
      Currently eventlog data is always written to a file `progname.eventlog`.
      This patch introduces the `flushEventLog` field in `RtsConfig` which
      allows to customize the writing of eventlog data.
      
      One possible scenario is the ongoing live-profile-monitor effort by
      @NCrashed which slurps all eventlog data through `fluchEventLog`.
      
      `flushEventLog` takes a buffer with eventlog data and its size and
      returns `false` (0) in case eventlog data could not be procesed.
      
      Reviewers: simonmar, austin, erikd, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: qnikst, thomie, NCrashed
      
      Differential Revision: https://phabricator.haskell.org/D2934
      4dfc6d1c
  12. 29 Nov, 2016 1 commit
  13. 03 Aug, 2016 2 commits
  14. 16 Jul, 2016 1 commit
  15. 11 May, 2016 1 commit
  16. 04 May, 2016 1 commit
  17. 26 Oct, 2015 1 commit
  18. 05 Sep, 2015 1 commit
  19. 12 Jun, 2015 1 commit
  20. 17 Feb, 2015 2 commits
    • thomie's avatar
      Don't truncate traceEvents to 512 bytes (#8309) · a82364c9
      thomie authored
      Summary:
      Don't call postLogMsg to post a user msg, because it truncates messages to
      512 bytes.
      
      Rename traceCap_stderr and trace_stderr to vtraceCap_stderr and trace_stderr,
      to signal that they take a va_list (similar to vdebugBelch vs debugBelch).
      
      See #3874 for the original reason behind traceFormatUserMsg.
      
      See the commit msg in #9395 (d360d440) for a discussion about using
      null-terminated strings vs strings with an explicit length.
      
      Test Plan:
      Run `cabal install ghc-events` and inspect the result of `ghc-events show` on
      an eventlog file created with `ghc -eventlog Test.hs` and `./Test +RTS -l`,
      where Test.hs contains:
      
      ```
      import Debug.Trace
      main = traceEvent (replicate 510 'a' ++ "bcd") $ return ()
      ```
      
      Depends on D655.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D656
      
      GHC Trac Issues: #8309
      a82364c9
    • thomie's avatar
      Add missing va_end to va_start · 310b6365
      thomie authored
      Summary: See also ab9711d8.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D655
      310b6365
  21. 29 Sep, 2014 1 commit
  22. 20 Aug, 2014 1 commit
  23. 28 Jul, 2014 1 commit
  24. 09 Jul, 2013 1 commit
  25. 16 Oct, 2012 1 commit
  26. 15 Oct, 2012 1 commit
    • Duncan Coutts's avatar
      Add a new traceMarker# primop for use in profiling output · a609027d
      Duncan Coutts authored
      In time-based profiling visualisations (e.g. heap profiles and ThreadScope)
      it would be useful to be able to mark particular points in the execution and
      have those points in time marked in the visualisation.
      
      The traceMarker# primop currently emits an event into the eventlog. In
      principle it could be extended to do something in the heap profiling too.
      a609027d
  27. 14 Sep, 2012 1 commit
  28. 07 Sep, 2012 1 commit
    • Simon Marlow's avatar
      Deprecate lnat, and use StgWord instead · 41737f12
      Simon Marlow authored
      lnat was originally "long unsigned int" but we were using it when we
      wanted a 64-bit type on a 64-bit machine.  This broke on Windows x64,
      where long == int == 32 bits.  Using types of unspecified size is bad,
      but what we really wanted was a type with N bits on an N-bit machine.
      StgWord is exactly that.
      
      lnat was mentioned in some APIs that clients might be using
      (e.g. StackOverflowHook()), so we leave it defined but with a comment
      to say that it's deprecated.
      41737f12
  29. 10 Jul, 2012 1 commit
    • Duncan Coutts's avatar
      Define the task-tracking events · 54c98b68
      Duncan Coutts authored
      Based on initial patches by Mikolaj Konarski <mikolaj@well-typed.com>
      
      These new eventlog events are to let profiling tools keep track of all
      the OS threads that belong to an RTS capability at any moment in time.
      In the RTS, OS threads correspond to the Task abstraction, so that is
      what we track. There are events for tasks being created, migrated
      between capabilities and deleted. In particular the task creation event
      also records the kernel thread id which lets us match up the OS thread
      with data collected by others tools (in the initial use case with
      Linux's perf tool, but in principle also with DTrace).
      54c98b68
  30. 26 Apr, 2012 1 commit
    • Ian Lynagh's avatar
      Fix warnings on Win64 · 1dbe6d59
      Ian Lynagh authored
      Mostly this meant getting pointer<->int conversions to use the right
      sizes. lnat is now size_t, rather than unsigned long, as that seems a
      better match for how it's used.
      1dbe6d59
  31. 11 Apr, 2012 2 commits
  32. 04 Apr, 2012 4 commits
    • Mikolaj Konarski's avatar
      Add the GC_GLOBAL_SYNC event marking that all caps are stopped for GC · c294d95d
      Mikolaj Konarski authored
      Quoting design rationale by dcoutts: The event indicates that we're doing
      a stop-the-world GC and all other HECs should be between their GC_START
      and GC_END events at that moment. We don't want to use GC_STATS_GHC
      for that, because GC_STATS_GHC is for extra GHC-specific info,
      not something we have to rely on to be able to match the GC pauses
      across HECs to a particular global GC.
      c294d95d
    • Mikolaj Konarski's avatar
      Fix the timestamps in GC_START and GC_END events on the GC-initiating cap · 598109eb
      Mikolaj Konarski authored
      There was a discrepancy between GC times reported in +RTS -s
      and the timestamps of GC_START and GC_END events on the cap,
      on which +RTS -s stats for the given GC are based.
      This is fixed by posting the events with exactly the same timestamp
      as generated for the stat calculation. The calls posting the events
      are moved too, so that the events are emitted close to the time instant
      they claim to be emitted at. The GC_STATS_GHC was moved, too, ensuring
      it's emitted before the moved GC_END on all caps, which simplifies tools code.
      598109eb
    • Duncan Coutts's avatar
      Add new eventlog events for various heap and GC statistics · 65aaa9b2
      Duncan Coutts authored
      They cover much the same info as is available via the GHC.Stats module
      or via the '+RTS -s' textual output, but via the eventlog and with a
      better sampling frequency.
      
      We have three new generic heap info events and two very GHC-specific
      ones. (The hope is the general ones are usable by other implementations
      that use the same eventlog system, or indeed not so sensitive to changes
      in GHC itself.)
      
      The general ones are:
      
       * total heap mem allocated since prog start, on a per-HEC basis
       * current size of the heap (MBlocks reserved from OS for the heap)
       * current size of live data in the heap
      
      Currently these are all emitted by GHC at GC time (live data only at
      major GC).
      
      The GHC specific ones are:
      
       * an event giving various static heap paramaters:
         * number of generations (usually 2)
         * max size if any
         * nursary size
         * MBlock and block sizes
       * a event emitted on each GC containing:
         * GC generation (usually just 0,1)
         * total bytes copied
         * bytes lost to heap slop and fragmentation
         * the number of threads in the parallel GC (1 for serial)
         * the maximum number of bytes copied by any par GC thread
         * the total number of bytes copied by all par GC threads
           (these last three can be used to calculate an estimate of the
            work balance in parallel GCs)
      65aaa9b2
    • Duncan Coutts's avatar
      Add eventlog/trace stuff for capabilities: create/delete/enable/disable · f9c2e854
      Duncan Coutts authored
      Now that we can adjust the number of capabilities on the fly, we need
      this reflected in the eventlog. Previously the eventlog had a single
      startup event that declared a static number of capabilities. Obviously
      that's no good anymore.
      
      For compatability we're keeping the EVENT_STARTUP but adding new
      EVENT_CAP_CREATE/DELETE. The EVENT_CAP_DELETE is actually just the old
      EVENT_SHUTDOWN but renamed and extended (using the existing mechanism
      to extend eventlog events in a compatible way). So we now emit both
      EVENT_STARTUP and EVENT_CAP_CREATE. One day we will drop EVENT_STARTUP.
      
      Since reducing the number of capabilities at runtime does not really
      delete them, it just disables them, then we also have new events for
      disable/enable.
      
      The old EVENT_SHUTDOWN was in the scheduler class of events. The new
      EVENT_CAP_* events are in the unconditional class, along with the
      EVENT_CAPSET_* ones. Knowing when capabilities are created and deleted
      is crucial to making sense of eventlogs, you always want those events.
      In any case, they're extremely low volume.
      f9c2e854
  33. 23 Mar, 2012 1 commit
  34. 22 Mar, 2012 1 commit