Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Jan 27, 2011

  1. Simon Marlow

    Annotate thread stop events with the owner of the black hole

    So we can now get these in ThreadScope:
      19487000: cap 1: stopping thread 6 (blocked on black hole owned by thread 4)
    Note: needs an update to ghc-events.  Older ThreadScopes will just
    ignore the new information.
    authored January 27, 2011

Dec 15, 2010

  1. Simon Marlow

    Implement stack chunks and separate TSO/STACK objects

    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.
    authored December 15, 2010

Aug 23, 2010

  1. Simon Marlow

    Add a couple of missing tests for EAGER_BLACKHOLE

    This was leading to looping and excessive allocation, when the
    computation should have just blocked on the black hole.  
    Reported by Christian Höner zu Siederdissen <>
    on glasgow-haskell-users.
    authored August 23, 2010

Jun 11, 2010

  1. Fix #4131 missing UNTAG_CLOSURE in messageBlackHole()

    authored June 11, 2010

Jun 10, 2010

  1. Simon Marlow

    messageBlackHole: fix deadlock bug caused by a missing 'volatile'

    authored June 10, 2010

May 24, 2010

  1. Simon Marlow

    Add a missing UNTAG_CLOSURE, causing bus errors on Sparc

    We just about got away with this on x86 which isn't
    alignment-sensitive.  The result of the memory load is compared
    against a few different values, but there is a fallback case that
    happened to be the right thing when the pointer was tagged.  A good
    bug to find, nonetheless.
    authored May 24, 2010

Apr 01, 2010

  1. Simon Marlow

    Change the representation of the MVar blocked queue

    The list of threads blocked on an MVar is now represented as a list of
    separately allocated objects rather than being linked through the TSOs
    themselves.  This lets us remove a TSO from the list in O(1) time
    rather than O(n) time, by marking the list object.  Removing this
    linear component fixes some pathalogical performance cases where many
    threads were blocked on an MVar and became unreachable simultaneously
    (nofib/smp/threads007), or when sending an asynchronous exception to a
    TSO in a long list of thread blocked on an MVar.
    MVar performance has actually improved by a few percent as a result of
    this change, slightly to my surprise.
    This is the final cleanup in the sequence, which let me remove the old
    way of waking up threads (unblockOne(), MSG_WAKEUP) in favour of the
    new way (tryWakeupThread and MSG_TRY_WAKEUP, which is idempotent).  It
    is now the case that only the Capability that owns a TSO may modify
    its state (well, almost), and this simplifies various things.  More of
    the RTS is based on message-passing between Capabilities now.
    authored April 01, 2010

Mar 29, 2010

  1. Simon Marlow

    Move a thread to the front of the run queue when another thread block…

    …s on it
    This fixes #3838, and was made possible by the new BLACKHOLE
    infrastructure.  To allow reording of the run queue I had to make it
    doubly-linked, which entails some extra trickiness with regard to
    GC write barriers and suchlike.
    authored March 29, 2010
  2. Simon Marlow

    change throwTo to use tryWakeupThread rather than unblockOne

    authored March 29, 2010
  3. Simon Marlow

    New implementation of BLACKHOLEs

    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.
    authored March 29, 2010
Something went wrong with that request. Please try again.