1. 19 May, 2014 1 commit
  2. 04 May, 2014 1 commit
  3. 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.
      b0534f78
  4. 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
  5. 24 Mar, 2014 1 commit
  6. 23 Mar, 2014 1 commit
  7. 13 Mar, 2014 1 commit
  8. 28 Nov, 2013 1 commit
  9. 26 Oct, 2013 1 commit
  10. 25 Oct, 2013 1 commit
  11. 23 Sep, 2013 2 commits
  12. 06 Aug, 2013 1 commit
  13. 15 Jun, 2013 2 commits
    • aljee@hyper.cx's avatar
      fe652a8b
    • aljee@hyper.cx's avatar
      Allow multiple C finalizers to be attached to a Weak# · d61c623e
      aljee@hyper.cx authored
      The commit replaces mkWeakForeignEnv# with addCFinalizerToWeak#.
      This new primop mutates an existing Weak# object and adds a new
      C finalizer to it.
      
      This change removes an invariant in MarkWeak.c, namely that the relative
      order of Weak# objects in the list needs to be preserved across GC. This
      makes it easier to split the list into per-generation structures.
      
      The patch also removes a race condition between two threads calling
      finalizeWeak# on the same WEAK object at that same time.
      d61c623e
  14. 29 Mar, 2013 1 commit
    • nfrisby's avatar
      ticky enhancements · 460abd75
      nfrisby authored
        * the new StgCmmArgRep module breaks a dependency cycle; I also
          untabified it, but made no real changes
      
        * updated the documentation in the wiki and change the user guide to
          point there
      
        * moved the allocation enters for ticky and CCS to after the heap check
      
          * I left LDV where it was, which was before the heap check at least
            once, since I have no idea what it is
      
        * standardized all (active?) ticky alloc totals to bytes
      
        * in order to avoid double counting StgCmmLayout.adjustHpBackwards
          no longer bumps ALLOC_HEAP_ctr
      
        * I resurrected the SLOW_CALL counters
      
          * the new module StgCmmArgRep breaks cyclic dependency between
            Layout and Ticky (which the SLOW_CALL counters cause)
      
          * renamed them SLOW_CALL_fast_<pattern> and VERY_SLOW_CALL
      
        * added ALLOC_RTS_ctr and _tot ticky counters
      
          * eg allocation by Storage.c:allocate or a BUILD_PAP in stg_ap_*_info
      
          * resurrected ticky counters for ALLOC_THK, ALLOC_PAP, and
            ALLOC_PRIM
      
          * added -ticky and -DTICKY_TICKY in ways.mk for debug ways
      
        * added a ticky counter for total LNE entries
      
        * new flags for ticky: -ticky-allocd -ticky-dyn-thunk -ticky-LNE
      
          * all off by default
      
          * -ticky-allocd: tracks allocation *of* closure in addition to
             allocation *by* that closure
      
          * -ticky-dyn-thunk tracks dynamic thunks as if they were functions
      
          * -ticky-LNE tracks LNEs as if they were functions
      
        * updated the ticky report format, including making the argument
          categories (more?) accurate again
      
        * the printed name for things in the report include the unique of
          their ticky parent as well as if they are not top-level
      460abd75
  15. 14 Feb, 2013 1 commit
  16. 01 Feb, 2013 1 commit
    • gmainlan@microsoft.com's avatar
      Add support for passing SSE vectors in registers. · 33bfc6a7
      gmainlan@microsoft.com authored
      This patch adds support for 6 XMM registers on x86-64 which overlap with the F
      and D registers and may hold 128-bit wide SIMD vectors. Because there is not a
      good way to attach type information to STG registers, we aggressively bitcast in
      the LLVM back-end.
      33bfc6a7
  17. 17 Nov, 2012 1 commit
  18. 16 Nov, 2012 1 commit
  19. 13 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Fix the OFFSET macro · 53e9916f
      ian@well-typed.com authored
      When offsetof is defined, we use that. This avoids "variably
      modified at file scope" warnings/errors with recent gccs.
      53e9916f
  20. 12 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Replace mkDerivedConstants.c with DeriveConstants.hs · f49271c0
      ian@well-typed.com authored
      DeriveConstants.hs works in a cross-compilation-friendly way. Rather
      than running a C program that prints out the constants, we just compile
      a C file which has the constants are encoded in symbol sizes. We then
      parse the output of 'nm' to find out what the constants are.
      
      Based on work by Gabor Greif <ggreif@gmail.com>.
      f49271c0