1. 23 Nov, 2008 1 commit
  2. 22 Nov, 2008 4 commits
  3. 21 Nov, 2008 6 commits
    • Thomas Schilling's avatar
      34837046
    • Thomas Schilling's avatar
      eb0e20bd
    • 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
    • Simon Marlow's avatar
      c373ebdb
    • Thomas Schilling's avatar
      Throw SourceErrors instead of ProgramErrors in main/HeaderInfo. · f7fd7fce
      Thomas Schilling authored
      Parse errors during dependency analysis or options parsing really
      shouldn't kill GHC; this is particularly annoying for GHC API clients.
      f7fd7fce
    • Simon Marlow's avatar
      fix the build when !USE_MMAP · 51e6b90f
      Simon Marlow authored
      51e6b90f
  4. 20 Nov, 2008 4 commits
  5. 19 Nov, 2008 5 commits
  6. 14 Nov, 2008 1 commit
  7. 19 Nov, 2008 2 commits
    • Simon Marlow's avatar
      Fix typo (HAVE_LIBGMP => HAVE_LIB_GMP); omit local gmp includes if HAVE_LIB_GMP · a6e1fda4
      Simon Marlow authored
      If we're using the system's installed GMP, we don't want to be picking
      up the local gmp.h header file.
      
      Fixes 2469(ghci) for me, because it turns out the system's GMP is more
      up-to-date than GHC's version and has a fix for more recent versions
      of gcc.  We also need to pull in a more recent GMP, but that's a
      separte issue.
      a6e1fda4
    • 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
  8. 14 Nov, 2008 1 commit
  9. 18 Nov, 2008 1 commit
    • Simon Marlow's avatar
      Add optional eager black-holing, with new flag -feager-blackholing · d600bf7a
      Simon Marlow authored
      Eager blackholing can improve parallel performance by reducing the
      chances that two threads perform the same computation.  However, it
      has a cost: one extra memory write per thunk entry.  
      
      To get the best results, any code which may be executed in parallel
      should be compiled with eager blackholing turned on.  But since
      there's a cost for sequential code, we make it optional and turn it on
      for the parallel package only.  It might be a good idea to compile
      applications (or modules) with parallel code in with
      -feager-blackholing.
      
      ToDo: document -feager-blackholing.
      d600bf7a
  10. 17 Nov, 2008 5 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
      fix compile breakage on Windows · 27f66c28
      Simon Marlow authored
      27f66c28
    • Simon Marlow's avatar
      Attempt to fix #2512 and #2063; add +RTS -xm<address> -RTS option · 11f6f411
      Simon Marlow authored
      On x86_64, the RTS needs to allocate memory in the low 2Gb of the
      address space.  On Linux we can do this with MAP_32BIT, but sometimes
      this doesn't work (#2512) and other OSs don't support it at all
      (#2063).  So to work around this:
      
        - Try MAP_32BIT first, if available.
      
        - Otherwise, try allocating memory from a fixed address (by default
          1Gb)
      
        - We now provide an option to configure the address to allocate
          from.  This allows a workaround on machines where the default
          breaks, and also provides a way for people to test workarounds
          that we can incorporate in future releases.
      11f6f411
    • 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
  11. 16 Nov, 2008 2 commits
  12. 14 Nov, 2008 7 commits
  13. 13 Nov, 2008 1 commit