1. 24 Apr, 2009 1 commit
  2. 23 Apr, 2009 3 commits
  3. 03 Apr, 2009 1 commit
  4. 20 Apr, 2009 1 commit
  5. 13 Apr, 2009 5 commits
  6. 03 Apr, 2009 2 commits
  7. 04 Apr, 2009 1 commit
  8. 03 Apr, 2009 3 commits
  9. 02 Apr, 2009 2 commits
  10. 31 Mar, 2009 1 commit
  11. 30 Mar, 2009 2 commits
  12. 26 Mar, 2009 1 commit
  13. 22 Mar, 2009 2 commits
  14. 23 Mar, 2009 1 commit
  15. 20 Mar, 2009 2 commits
  16. 18 Mar, 2009 1 commit
  17. 20 Mar, 2009 2 commits
  18. 19 Mar, 2009 1 commit
  19. 18 Mar, 2009 3 commits
  20. 17 Mar, 2009 3 commits
    • Simon Marlow's avatar
      Add fast event logging · 8b18faef
      Simon Marlow authored
      Generate binary log files from the RTS containing a log of runtime
      events with timestamps.  The log file can be visualised in various
      ways, for investigating runtime behaviour and debugging performance
      problems.  See for example the forthcoming ThreadScope viewer.
      
      New GHC option:
      
        -eventlog   (link-time option) Enables event logging.
      
        +RTS -l     (runtime option) Generates <prog>.eventlog with
                    the binary event information.
      
      This replaces some of the tracing machinery we already had in the RTS:
      e.g. +RTS -vg  for GC tracing (we should do this using the new event
      logging instead).
      
      Event logging has almost no runtime cost when it isn't enabled, though
      in the future we might add more fine-grained events and this might
      change; hence having a link-time option and compiling a separate
      version of the RTS for event logging.  There's a small runtime cost
      for enabling event-logging, for most programs it shouldn't make much
      difference.
      
      (Todo: docs)
      8b18faef
    • Simon Marlow's avatar
      FIX biographical profiling (#3039, probably #2297) · f8f4cb3f
      Simon Marlow authored
      Since we introduced pointer tagging, we no longer always enter a
      closure to evaluate it.  However, the biographical profiler relies on
      closures being entered in order to mark them as "used", so we were
      getting spurious amounts of data attributed to VOID.  It turns out
      there are various places that need to be fixed, and I think at least
      one of them was also wrong before pointer tagging (CgCon.cgReturnDataCon).
      f8f4cb3f
    • Simon Marlow's avatar
      Add getNumberOfProcessors(), FIX MacOS X build problem (hopefully) · 0ee0be10
      Simon Marlow authored
      Somebody needs to implement getNumberOfProcessors() for MacOS X,
      currently it will return 1.
      0ee0be10
  21. 16 Mar, 2009 2 commits