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. 29 Aug, 2009 1 commit
    • Simon Marlow's avatar
      Unify event logging and debug tracing. · a5288c55
      Simon Marlow authored
        - tracing facilities are now enabled with -DTRACING, and -DDEBUG
          additionally enables debug-tracing.  -DEVENTLOG has been
          removed.
      
        - -debug now implies -eventlog
      
        - events can be printed to stderr instead of being sent to the
          binary .eventlog file by adding +RTS -v (which is implied by the
          +RTS -Dx options).
      
        - -Dx debug messages can be sent to the binary .eventlog file
          by adding +RTS -l.  This should help debugging by reducing
          the impact of debug tracing on execution time.
      
        - Various debug messages that duplicated the information in events
          have been removed.
      a5288c55
  2. 30 Aug, 2009 1 commit
  3. 29 Aug, 2009 1 commit
  4. 20 Aug, 2009 2 commits
  5. 19 Aug, 2009 2 commits
  6. 03 Aug, 2009 2 commits
  7. 02 Aug, 2009 1 commit
    • Simon Marlow's avatar
      RTS tidyup sweep, first phase · a2a67cd5
      Simon Marlow authored
      The first phase of this tidyup is focussed on the header files, and in
      particular making sure we are exposinng publicly exactly what we need
      to, and no more.
      
       - Rts.h now includes everything that the RTS exposes publicly,
         rather than a random subset of it.
      
       - Most of the public header files have moved into subdirectories, and
         many of them have been renamed.  But clients should not need to
         include any of the other headers directly, just #include the main
         public headers: Rts.h, HsFFI.h, RtsAPI.h.
      
       - All the headers needed for via-C compilation have moved into the
         stg subdirectory, which is self-contained.  Most of the headers for
         the rest of the RTS APIs have moved into the rts subdirectory.
      
       - I left MachDeps.h where it is, because it is so widely used in
         Haskell code.
       
       - I left a deprecated stub for RtsFlags.h in place.  The flag
         structures are now exposed by Rts.h.
      
       - Various internal APIs are no longer exposed by public header files.
      
       - Various bits of dead code and declarations have been removed
      
       - More gcc warnings are turned on, and the RTS code is more
         warning-clean.
      
       - More source files #include "PosixSource.h", and hence only use
         standard POSIX (1003.1c-1995) interfaces.
      
      There is a lot more tidying up still to do, this is just the first
      pass.  I also intend to standardise the names for external RTS APIs
      (e.g use the rts_ prefix consistently), and declare the internal APIs
      as hidden for shared libraries.
      a2a67cd5
  8. 10 Jun, 2009 1 commit
  9. 02 Jun, 2009 1 commit
  10. 29 May, 2009 1 commit
  11. 28 May, 2009 1 commit
  12. 18 May, 2009 1 commit
  13. 28 Apr, 2009 1 commit
  14. 03 Apr, 2009 1 commit
  15. 26 Mar, 2009 1 commit
  16. 18 Mar, 2009 1 commit
  17. 17 Mar, 2009 1 commit
    • 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
  18. 13 Mar, 2009 1 commit
    • Simon Marlow's avatar
      Instead of a separate context-switch flag, set HpLim to zero · 304e7fb7
      Simon Marlow authored
      This reduces the latency between a context-switch being triggered and
      the thread returning to the scheduler, which in turn should reduce the
      cost of the GC barrier when there are many cores.
      
      We still retain the old context_switch flag which is checked at the
      end of each block of allocation.  The idea is that setting HpLim may
      fail if the the target thread is modifying HpLim at the same time; the
      context_switch flag is a fallback.  It also allows us to "context
      switch soon" without forcing an immediate switch, which can be costly.
      304e7fb7
  19. 09 Mar, 2009 1 commit
  20. 03 Mar, 2009 1 commit
  21. 09 Feb, 2009 1 commit
  22. 14 Jan, 2009 1 commit
    • Simon Marlow's avatar
      Detect when a C finalizer calls back to Haskell · 348e8f80
      Simon Marlow authored
      This is illegal now, after the fix for #1364, but it turns out that
      the existing check for dodgy callbacks doesn't catch finalizers
      calling back, so we need another test.  This will be particularly
      important for 6.10.2, because the behaviour has changed.
      348e8f80
  23. 07 Jan, 2009 2 commits
  24. 06 Jan, 2009 1 commit
  25. 10 Dec, 2008 1 commit
  26. 09 Dec, 2008 1 commit
  27. 21 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Use mutator threads to do GC, instead of having a separate pool of GC threads · 3ebcd3de
      Simon Marlow authored
      Previously, the GC had its own pool of threads to use as workers when
      doing parallel GC.  There was a "leader", which was the mutator thread
      that initiated the GC, and the other threads were taken from the pool.
      
      This was simple and worked fine for sequential programs, where we did
      most of the benchmarking for the parallel GC, but falls down for
      parallel programs.  When we have N mutator threads and N cores, at GC
      time we would have to stop N-1 mutator threads and start up N-1 GC
      threads, and hope that the OS schedules them all onto separate cores.
      It practice it doesn't, as you might expect.
      
      Now we use the mutator threads to do GC.  This works quite nicely,
      particularly for parallel programs, where each mutator thread scans
      its own spark pool, which is probably in its cache anyway.
      
      There are some flag changes:
      
        -g<n> is removed (-g1 is still accepted for backwards compat).
        There's no way to have a different number of GC threads than mutator
        threads now.
      
        -q1       Use one OS thread for GC (turns off parallel GC)
        -qg<n>    Use parallel GC for generations >= <n> (default: 1)
      
      Using parallel GC only for generations >=1 works well for sequential
      programs.  Compiling an ordinary sequential program with -threaded and
      running it with -N2 or more should help if you do a lot of GC.  I've
      found that adding -qg0 (do parallel GC for generation 0 too) speeds up
      some parallel programs, but slows down some sequential programs.
      Being conservative, I left the threshold at 1.
      
      ToDo: document the new options.
      3ebcd3de
  28. 20 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Fix a race in the deadlock-detection code · 117dc73b
      Simon Marlow authored
      After a deadlock it was possible for the timer signal to remain off,
      which meant that the next deadlock would not be detected, and the
      system would hang.  Spotted by conc047(threaded2).
      117dc73b
  29. 19 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Fix some more shutdown races · 5cbe7adb
      Simon Marlow authored
      There were races between workerTaskStop() and freeTaskManager(): we
      need to be sure that all Tasks have exited properly before we start
      tearing things down.  This isn't completely straighforward, see
      comments for details.
      5cbe7adb
  30. 17 Nov, 2008 3 commits
    • Simon Marlow's avatar
      Fix #2783: detect black-hole loops properly · 0fa59deb
      Simon Marlow authored
      At some point we regressed on detecting simple black-hole loops.  This
      happened due to the introduction of duplicate-work detection for
      parallelism: a black-hole loop looks very much like duplicate work,
      except it's duplicate work being performed by the very same thread.
      So we have to detect and handle this case.
      0fa59deb
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Another shutdown fix · cb905327
      Simon Marlow authored
      If we encounter a runnable thread during shutdown, just kill it.  All
      the threads are supposed to be dead at this stage, but this catches
      threads that might have just returned from a foreign call, or were
      finalizers created by the GC.
      
      Fixes memo002(threaded1)
      cb905327
  31. 13 Nov, 2008 2 commits
    • Simon Marlow's avatar
      Fix another subtle shutdown deadlock · dddfba38
      Simon Marlow authored
      The problem occurred when a thread tries to GC during shutdown.  In
      order to GC it has to acquire all the Capabilities in the system, but
      during shutdown, some of the Capabilities have already been closed and
      can never be acquired.
      dddfba38
    • Simon Marlow's avatar
      Fix an extremely subtle deadlock bug on x86_64 · 6d316585
      Simon Marlow authored
      The recent_activity flag was an unsigned int, but we sometimes do a
      64-bit xchg() on it, which overwrites the next word in memory.  This
      happened to contain the sched_state flag, which is used to control the
      orderly shutdown of the system.  If the xchg() happened during
      shutdown, the scheduler would get confused and deadlock.  Don't you
      just love C?
      6d316585
  32. 06 Nov, 2008 2 commits