• 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.
Capability.c 25.8 KB