1. 24 Apr, 2010 1 commit
  2. 23 Apr, 2010 1 commit
  3. 22 Apr, 2010 3 commits
  4. 21 Apr, 2010 2 commits
  5. 20 Apr, 2010 3 commits
  6. 31 Mar, 2010 1 commit
  7. 13 Apr, 2010 1 commit
  8. 16 Apr, 2010 2 commits
  9. 12 Apr, 2010 2 commits
  10. 15 Apr, 2010 2 commits
  11. 12 Apr, 2010 2 commits
  12. 09 Apr, 2010 2 commits
  13. 30 Mar, 2010 1 commit
  14. 07 Apr, 2010 5 commits
  15. 06 Apr, 2010 5 commits
  16. 01 Apr, 2010 3 commits
    • Simon Marlow's avatar
      fix bug in migrateThread() · 20fcaaba
      Simon Marlow authored
      20fcaaba
    • Simon Marlow's avatar
      Remove the IND_OLDGEN and IND_OLDGEN_PERM closure types · 70a2431f
      Simon Marlow 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.
      70a2431f
    • 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.
      f4692220
  17. 30 Mar, 2010 1 commit
  18. 01 Apr, 2010 1 commit
  19. 29 Mar, 2010 1 commit
  20. 30 Mar, 2010 1 commit