1. 27 Jul, 2015 1 commit
  2. 22 Jul, 2015 1 commit
    • Simon Marlow's avatar
      Eliminate zero_static_objects_list() · b949c96b
      Simon Marlow authored
      Summary:
      In a workload with a large amount of code, zero_static_objects_list()
      takes a significant amount of time, and furthermore it is in the
      single-threaded part of the GC.
      
      This patch uses a slightly fiddly scheme for marking objects on the
      static object lists, using a flag in the low 2 bits that flips between
      two states to indicate whether an object has been visited during this
      GC or not.  We also have to take into account objects that have not
      been visited yet, which might appear at any time due to runtime linking.
      
      Test Plan: validate
      
      Reviewers: austin, bgamari, ezyang, rwbarton
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1076
      b949c96b
  3. 13 Jan, 2015 1 commit
  4. 05 Dec, 2014 1 commit
  5. 02 Dec, 2014 1 commit
    • Simon Peyton Jones's avatar
      Revert "Make the linker API thread-safe" · 4b51194d
      Simon Peyton Jones authored
      This reverts commit b5e8b3b1.
      
      I reverted it because one of these two patches
        9e6e4796 Add purgeObj()
        b5e8b3b1 Make the linker API thread-safe
      
      causes a seg-fault on Windows.  The seg-fault happens immediately
      the linker is invoked, in ghci or in Template Haskell.
      
      I believe that it is the "linker API thread-safe" commit that causes
      the seg-fault; it happens even if the "purgeObj" commit alone is
      reverted.  But since the two patches mess with the same code, to
      revert the "linker API" patch I had revert both.
      4b51194d
  6. 28 Nov, 2014 1 commit
    • Simon Marlow's avatar
      Make the linker API thread-safe · b5e8b3b1
      Simon Marlow authored
      We used to be able to rely on the client to use the API in a
      single-threaded way, but now that the GC calls into the linker to
      unload objects this isn't a safe assumption.
      b5e8b3b1
  7. 21 Oct, 2014 1 commit
  8. 29 Sep, 2014 1 commit
  9. 28 Jul, 2014 1 commit
  10. 13 Apr, 2014 1 commit
  11. 29 Mar, 2014 1 commit
    • tibbe's avatar
      Add SmallArray# and SmallMutableArray# types · 90329b6c
      tibbe authored
      These array types are smaller than Array# and MutableArray# and are
      faster when the array size is small, as they don't have the overhead
      of a card table. Having no card table reduces the closure size with 2
      words in the typical small array case and leads to less work when
      updating or GC:ing the array.
      
      Reduces both the runtime and memory allocation by 8.8% on my insert
      benchmark for the HashMap type in the unordered-containers package,
      which makes use of lots of small arrays. With tuned GC settings
      (i.e. `+RTS -A6M`) the runtime reduction is 15%.
      
      Fixes #8923.
      90329b6c
  12. 21 Nov, 2013 1 commit
  13. 04 Sep, 2013 2 commits
  14. 22 Aug, 2013 1 commit
    • Simon Marlow's avatar
      Really unload object code when it is safe to do so (#8039) · bdfefb3b
      Simon Marlow authored
      The next major GC after an unloadObj() will do a traversal of the heap
      to determine whether the object code can be removed from memory or
      not.  We'll keep doing these until it is safe to remove the object
      code.
      
      In my experiments with GHCi, the objects get unloaded immediately,
      which is a good sign: we're not accidentally holding on to any
      references anywhere in the GHC data structures.
      
      Changes relative to the patch earlier posted on the ticket:
       - fix two memory leaks discovered with Valgrind, after
         testing with tests/rts/linker_unload.c
      bdfefb3b