1. 19 Mar, 2015 1 commit
  2. 23 Feb, 2015 1 commit
  3. 12 Nov, 2014 1 commit
  4. 21 Oct, 2014 1 commit
  5. 29 Sep, 2014 1 commit
  6. 01 Aug, 2014 1 commit
  7. 28 Jul, 2014 1 commit
  8. 04 May, 2014 1 commit
  9. 02 May, 2014 1 commit
    • Simon Marlow's avatar
      Per-thread allocation counters and limits · b0534f78
      Simon Marlow authored
      This tracks the amount of memory allocation by each thread in a
      counter stored in the TSO.  Optionally, when the counter drops below
      zero (it counts down), the thread can be sent an asynchronous
      exception: AllocationLimitExceeded.  When this happens, given a small
      additional limit so that it can handle the exception.  See
      documentation in GHC.Conc for more details.
      Allocation limits are similar to timeouts, but
        - timeouts use real time, not CPU time.  Allocation limits do not
          count anything while the thread is blocked or in foreign code.
        - timeouts don't re-trigger if the thread catches the exception,
          allocation limits do.
        - timeouts can catch non-allocating loops, if you use
          -fno-omit-yields.  This doesn't work for allocation limits.
      I couldn't measure any impact on benchmarks with these changes, even
      for nofib/smp.
  10. 25 Oct, 2013 1 commit
  11. 12 Oct, 2013 1 commit
  12. 11 Oct, 2013 2 commits
  13. 10 Oct, 2013 1 commit
  14. 03 Oct, 2013 1 commit
  15. 08 Sep, 2013 2 commits
  16. 04 Sep, 2013 1 commit
    • Simon Marlow's avatar
      Don't move Capabilities in setNumCapabilities (#8209) · aa779e09
      Simon Marlow authored
      We have various problems with reallocating the array of Capabilities,
      due to threads in waitForReturnCapability that are already holding a
      pointer to a Capability.
      Rather than add more locking to make this safer, I decided it would be
      easier to ensure that we never move the Capabilities at all.  The
      capabilities array is now an array of pointers to Capabaility.  There
      are extra indirections, but it rarely matters - we don't often access
      Capabilities via the array, normally we already have a pointer to
      one.  I ran the parallel benchmarks and didn't see any difference.
  17. 09 Jul, 2013 1 commit
  18. 22 Apr, 2013 1 commit
  19. 07 Sep, 2012 2 commits
    • Simon Marlow's avatar
      Lots of nat -> StgWord changes · bf2d58c2
      Simon Marlow authored
    • Simon Marlow's avatar
      Deprecate lnat, and use StgWord instead · 41737f12
      Simon Marlow authored
      lnat was originally "long unsigned int" but we were using it when we
      wanted a 64-bit type on a 64-bit machine.  This broke on Windows x64,
      where long == int == 32 bits.  Using types of unspecified size is bad,
      but what we really wanted was a type with N bits on an N-bit machine.
      StgWord is exactly that.
      lnat was mentioned in some APIs that clients might be using
      (e.g. StackOverflowHook()), so we leave it defined but with a comment
      to say that it's deprecated.
  20. 12 Apr, 2012 2 commits
  21. 28 Mar, 2012 2 commits
    • Simon Marlow's avatar
      threadStackOverflow: Tweak to stack chunk sizing · fe0a45ef
      Simon Marlow authored
      If the old stack is only half full, then the next chunk we allocate
      will be twice as large, to accommodate large requests for stack.  In
      that case, make sure that the chunk we allocate is at least as large
      as the usual chunk size - there's no point allocating a 2k chunk
      (double the default initial chunk size of 1k) if in the normal case we
      would allocate a 32k chunk.
    • Simon Marlow's avatar
      Fix a bug in threadStackOverflow() (maybe #5214) · 734f1d48
      Simon Marlow authored
      If we overflow the current stack chunk and copy its entire contents
      into the next stack chunk, we could end up with two UNDERFLOW_FRAMEs.
      We had a special case to catch this in the case when the old stack
      chunk was the last one (ending in STOP_FRAME), but it went wrong for
      other chunks.
      I found this bug while poking around in the core dump attached to
      options and running the nofib suite: imaginary/wheel_sieve2 crashed
      with +RTS -kc600 -kb300.
      I don't know if this is the cause of all the symptoms reported in
  22. 05 Jan, 2012 1 commit
  23. 25 Nov, 2011 1 commit
    • Simon Marlow's avatar
      Time handling overhaul · 6b109851
      Simon Marlow authored
      Terminology cleanup: the type "Ticks" has been renamed "Time", which
      is an StgWord64 in units of TIME_RESOLUTION (currently nanoseconds).
      The terminology "tick" is now used consistently to mean the interval
      between timer signals.
      The ticker now always ticks in realtime (actually CLOCK_MONOTONIC if
      we have it).  Before it used CPU time in the non-threaded RTS and
      realtime in the threaded RTS, but I've discovered that the CPU timer
      has terrible resolution (at least on Linux) and isn't much use for
      profiling.  So now we always use realtime.  This should also fix
      The default tick interval is now 10ms, except when profiling where we
      drop it to 1ms.  This gives more accurate profiles without affecting
      runtime too much (<1%).
      Lots of cleanups - the resolution of Time is now in one place
      only (Rts.h) rather than having calculations that depend on the
      resolution scattered all over the RTS.  I hope I found them all.
  24. 02 Feb, 2011 1 commit
    • Simon Marlow's avatar
      GC refactoring and cleanup · 18896fa2
      Simon Marlow authored
      Now we keep any partially-full blocks in the gc_thread[] structs after
      each GC, rather than moving them to the generation.  This should give
      us slightly better locality (though I wasn't able to measure any
      Also in this patch: better sanity checking with THREADED.
  25. 16 Dec, 2010 1 commit
  26. 15 Dec, 2010 2 commits
    • Simon Marlow's avatar
      fix for large stack allocations · 4f376647
      Simon Marlow authored
    • Simon Marlow's avatar
      Implement stack chunks and separate TSO/STACK objects · f30d5273
      Simon Marlow 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.
  27. 02 Dec, 2010 1 commit
  28. 13 Oct, 2010 1 commit
  29. 19 Sep, 2010 1 commit
    • Edward Z. Yang's avatar
      Interruptible FFI calls with pthread_kill and CancelSynchronousIO. v4 · 83d563cb
      Edward Z. Yang authored
      This is patch that adds support for interruptible FFI calls in the form
      of a new foreign import keyword 'interruptible', which can be used
      instead of 'safe' or 'unsafe'.  Interruptible FFI calls act like safe
      FFI calls, except that the worker thread they run on may be interrupted.
      Internally, it replaces BlockedOnCCall_NoUnblockEx with
      BlockedOnCCall_Interruptible, and changes the behavior of the RTS
      to not modify the TSO_ flags on the event of an FFI call from
      a thread that was interruptible.  It also modifies the bytecode
      format for foreign call, adding an extra Word16 to indicate
      The semantics of interruption vary from platform to platform, but the
      intent is that any blocking system calls are aborted with an error code.
      This is most useful for making function calls to system library
      functions that support interrupting.  There is no support for pre-Vista
      There is a partner testsuite patch which adds several tests for this
  30. 23 Aug, 2010 1 commit
    • Simon Marlow's avatar
      Add a couple of missing tests for EAGER_BLACKHOLE · fd316eba
      Simon Marlow authored
      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 <choener@tbi.univie.ac.at>
      on glasgow-haskell-users.
  31. 07 Apr, 2010 1 commit
  32. 06 Apr, 2010 1 commit
  33. 01 Apr, 2010 2 commits
    • Simon Marlow's avatar
      fix bug in migrateThread() · 20fcaaba
      Simon Marlow authored
    • Simon Marlow's avatar
      Change the representation of the MVar blocked queue · f4692220
      Simon Marlow authored
      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.