1. 15 Dec, 2010 1 commit
    • 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.
  2. 09 Dec, 2010 1 commit
  3. 10 Dec, 2010 3 commits
  4. 09 Dec, 2010 1 commit
  5. 08 Dec, 2010 2 commits
  6. 03 Dec, 2010 3 commits
  7. 02 Dec, 2010 1 commit
  8. 26 Nov, 2010 1 commit
  9. 30 Nov, 2010 4 commits
  10. 27 Nov, 2010 4 commits
  11. 25 Nov, 2010 1 commit
  12. 23 Nov, 2010 2 commits
  13. 29 Oct, 2010 1 commit
  14. 05 Nov, 2010 1 commit
  15. 14 Nov, 2010 1 commit
  16. 13 Nov, 2010 1 commit
  17. 11 Nov, 2010 1 commit
  18. 01 Nov, 2010 1 commit
  19. 29 Oct, 2010 4 commits
  20. 28 Oct, 2010 1 commit
  21. 13 Oct, 2010 1 commit
  22. 26 Oct, 2010 1 commit
    • gwright@antiope.com's avatar
      Fix for #4318 (Linker failure on OS X 10.6) · 73dd6e84
      gwright@antiope.com authored
      This patch fixes two bugs in the Mach-O linker and adds debugging statements
      to the same. The bugs:
      1. The test for symbol->n_value == 0 is removed and replaced by a test of the
      flag field.  Checking the n_value field was just wrong; the value of a
      symbol should only be examined when allocating space for a common block,
      in which case the n_value field gives the size of the block.  This bug
      led to an infrequently occuring linker crash.
      I believe the behavior of the linker now agrees with the intent of the
      sketchy Apple documentation.
      2. Jump islands were being filled with garbage instead of the the location
      of the referenced symbol. This caused relocations of type X86_64_RELOC_GOT and
      X86_64_RELOC_GOT_LOAD to eventually lead to crashes.  The fix is simply to
      look up the symbol.
      Enough debug statements have been added to follow the operation of the Mach-O
      linker while it loads modules.  They are not yet as informative and well
      organized as for ELF.  Improving the debug statements will require some
      reorganization of the code -- the Mach-O linker seems basically sound, but
      is crying out for some refactoring and commenting.
  23. 23 Oct, 2010 1 commit
  24. 19 Oct, 2010 1 commit
    • Ian Lynagh's avatar
      Fix a retainer profiling segfault · 140aeb39
      Ian Lynagh authored
      The bitmap type wasn't big enough to hold large bitmaps on 64 bit
      platforms. Profiling GHC was segfaulting when retainStack was handling a
      size 33 bitmap.
  25. 27 Sep, 2010 1 commit