Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Dec 15, 2010
  1. @simonmar

    Implement stack chunks and separate TSO/STACK objects

    simonmar authored
    This patch makes two changes to the way stacks are managed:
    1. The stack is now stored in a separate object from the TSO.
    This means that it is easier to replace the stack object for a thread
    when the stack overflows or underflows; we don't have to leave behind
    the old TSO as an indirection any more.  Consequently, we can remove
    ThreadRelocated and deRefTSO(), which were a pain.
    This is obviously the right thing, but the last time I tried to do it
    it made performance worse.  This time I seem to have cracked it.
    2. Stacks are now represented as a chain of chunks, rather than
       a single monolithic object.
    The big advantage here is that individual chunks are marked clean or
    dirty according to whether they contain pointers to the young
    generation, and the GC can avoid traversing clean stack chunks during
    a young-generation collection.  This means that programs with deep
    stacks will see a big saving in GC overhead when using the default GC
    A secondary advantage is that there is much less copying involved as
    the stack grows.  Programs that quickly grow a deep stack will see big
    In some ways the implementation is simpler, as nothing special needs
    to be done to reclaim stack as the stack shrinks (the GC just recovers
    the dead stack chunks).  On the other hand, we have to manage stack
    underflow between chunks, so there's a new stack frame
    (UNDERFLOW_FRAME), and we now have separate TSO and STACK objects.
    The total amount of code is probably about the same as before.
    There are new RTS flags:
       -ki<size> Sets the initial thread stack size (default 1k)  Egs: -ki4k -ki2m
       -kc<size> Sets the stack chunk size (default 32k)
       -kb<size> Sets the stack chunk buffer size (default 1k)
    -ki was previously called just -k, and the old name is still accepted
    for backwards compatibility.  These new options are documented.
Commits on Apr 1, 2010
  1. @simonmar

    Remove the IND_OLDGEN and IND_OLDGEN_PERM closure types

    simonmar authored
    These are no longer used: once upon a time they used to have different
    layout from IND and IND_PERM respectively, but that is no longer the
    case since we changed the remembered set to be an array of addresses
    instead of a linked list of closures.
Commits on Mar 29, 2010
  1. @simonmar

    New implementation of BLACKHOLEs

    simonmar authored
    This replaces the global blackhole_queue with a clever scheme that
    enables us to queue up blocked threads on the closure that they are
    blocked on, while still avoiding atomic instructions in the common
     - gets rid of a locked global data structure and some tricky GC code
       (replacing it with some per-thread data structures and different
       tricky GC code :)
     - wakeups are more prompt: parallel/concurrent performance should
       benefit.  I haven't seen anything dramatic in the parallel
       benchmarks so far, but a couple of threading benchmarks do improve
       a bit.
     - waking up a thread blocked on a blackhole is now O(1) (e.g. if
       it is the target of throwTo).
     - less sharing and better separation of Capabilities: communication
       is done with messages, the data structures are strictly owned by a
       Capability and cannot be modified except by sending messages.
     - this change will utlimately enable us to do more intelligent
       scheduling when threads block on each other.  This is what started
       off the whole thing, but it isn't done yet (#3838).
    I'll be documenting all this on the wiki in due course.
Commits on Mar 11, 2010
  1. @simonmar

    Use message-passing to implement throwTo in the RTS

    simonmar authored
    This replaces some complicated locking schemes with message-passing
    in the implementation of throwTo. The benefits are
     - previously it was impossible to guarantee that a throwTo from
       a thread running on one CPU to a thread running on another CPU
       would be noticed, and we had to rely on the GC to pick up these
       forgotten exceptions. This no longer happens.
     - the locking regime is simpler (though the code is about the same
     - threads can be unblocked from a blocked_exceptions queue without
       having to traverse the whole queue now.  It's a rare case, but
       replaces an O(n) operation with an O(1).
     - generally we move in the direction of sharing less between
       Capabilities (aka HECs), which will become important with other
       changes we have planned.
    Also in this patch I replaced several STM-specific closure types with
    a generic MUT_PRIM closure type, which allowed a lot of code in the GC
    and other places to go away, hence the line-count reduction.  The
    message-passing changes resulted in about a net zero line-count
Commits on Aug 3, 2009
  1. @simonmar

    remove the GUM closure types

    simonmar authored
  2. @simonmar
Commits on Nov 18, 2008
  1. @simonmar

    Add optional eager black-holing, with new flag -feager-blackholing

    simonmar 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
    ToDo: document -feager-blackholing.
Commits on Oct 31, 2007
  1. Initial parallel GC support

    Simon Marlow authored
    eg. use +RTS -g2 -RTS for 2 threads.  Only major GCs are parallelised,
    minor GCs are still sequential. Don't use more threads than you
    have CPUs.
    It works most of the time, although you won't see much speedup yet.
    Tuning and more work on stability still required.
Commits on Oct 11, 2007
  1. Add a proper write barrier for MVars

    Simon Marlow authored
    Previously MVars were always on the mutable list of the old
    generation, which meant every MVar was visited during every minor GC.
    With lots of MVars hanging around, this gets expensive.  We addressed
    this problem for MUT_VARs (aka IORefs) a while ago, the solution is to
    use a traditional GC write-barrier when the object is modified.  This
    patch does the same thing for MVars.
    TVars are still done the old way, they could probably benefit from the
    same treatment too.
Commits on Jun 6, 2007
  1. Minor comment update

    Michael D. Adams authored
Commits on Feb 28, 2007
  1. Remove vectored returns.

    Simon Marlow authored
    We recently discovered that they aren't a win any more, and just cost
    code size.
Commits on Oct 7, 2006
  1. STM invariants authored
Commits on Sep 7, 2006
  1. Remove CONSTR_CHARLIKE and CONSTR_INTLIKE closure types

    Simon Marlow authored
    These closure types aren't used/needed, as far as I can tell.  The
    commoning up of Chars/Ints happens by comparing info pointers, and
    the info table for a dynamic C#/I# is CONSTR_0_1.  The RTS seemed
    a little confused about whether CONSTR_CHARLIKE/CONSTR_INTLIKE were
    supposed to be static or dynamic closures, too.
Commits on Apr 7, 2006
  1. Reorganisation of the source tree

    Simon Marlow authored
    Most of the other users of the fptools build system have migrated to
    Cabal, and with the move to darcs we can now flatten the source tree
    without losing history, so here goes.
    The main change is that the ghc/ subdir is gone, and most of what it
    contained is now at the top level.  The build system now makes no
    pretense at being multi-project, it is just the GHC build system.
    No doubt this will break many things, and there will be a period of
    instability while we fix the dependencies.  A straightforward build
    should work, but I haven't yet fixed binary/source distributions.
    Changes to the Building Guide will follow, too.
Something went wrong with that request. Please try again.