1. 21 Dec, 2015 1 commit
    • Simon Marlow's avatar
      Maintain cost-centre stacks in the interpreter · c8c44fd9
      Simon Marlow authored
      Breakpoints become SCCs, so we have detailed call-stack info for
      interpreted code.  Currently this only works when GHC is compiled with
      -prof, but D1562 (Remote GHCi) removes this constraint so that in the
      future call stacks will be available without building your own GHCi.
      How can you get a stack trace?
      * programmatically: GHC.Stack.currentCallStack
      * I've added an experimental :where command that shows the stack when
        stopped at a breakpoint
      * `error` attaches a call stack automatically, although since calls to
        `error` are often lifted out to the top level, this is less useful
        than it might be (ImplicitParams still works though).
      * Later we might attach call stacks to all exceptions
      Other related changes in this diff:
      * I reduced the number of places that get ticks attached for
        breakpoints.  In particular there was a breakpoint around the whole
        declaration, which was often redundant because it bound no variables.
        This reduces clutter in the stack traces and speeds up compilation.
      * I tidied up some RealSrcSpan stuff in InteractiveUI, and made a few
        other small cleanups
      Test Plan: validate
      Reviewers: ezyang, bgamari, austin, hvr
      Subscribers: thomie
      Differential Revision: https://phabricator.haskell.org/D1595
      GHC Trac Issues: #11047
  2. 12 Nov, 2015 1 commit
  3. 20 Oct, 2014 1 commit
  4. 02 Oct, 2014 1 commit
    • Edward Z. Yang's avatar
      Rename _closure to _static_closure, apply naming consistently. · 35672072
      Edward Z. Yang authored
      In preparation for indirecting all references to closures,
      we rename _closure to _static_closure to ensure any old code
      will get an undefined symbol error.  In order to reference
      a closure foobar_closure (which is now undefined), you should instead
      use STATIC_CLOSURE(foobar).  For convenience, a number of these
      old identifiers are macro'd.
      Across C-- and C (Windows and otherwise), there were differing
      conventions on whether or not foobar_closure or &foobar_closure
      was the address of the closure.  Now, all foobar_closure references
      are addresses, and no & is necessary.
      CHARLIKE/INTLIKE were not changed, simply alpha-renamed.
      Part of remove HEAP_ALLOCED patch set (#8199)
      Depends on D265
      Signed-off-by: Edward Z. Yang's avatarEdward Z. Yang <ezyang@mit.edu>
      Test Plan: validate
      Reviewers: simonmar, austin
      Subscribers: simonmar, ezyang, carter, thomie
      Differential Revision: https://phabricator.haskell.org/D267
      GHC Trac Issues: #8199
  5. 24 Sep, 2014 1 commit
  6. 17 Sep, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Implement `decodeDouble_Int64#` primop · b62bd5ec
      Herbert Valerio Riedel authored
      The existing `decodeDouble_2Int#` primop is rather inconvenient to use
      (and in fact is not even used by `integer-gmp`) as the mantissa is split
      into 3 components which would actually fit in an `Int64#` value.
      However, `decodeDouble_Int64#` is to be used by the new `integer-gmp2`
      re-implementation (see #9281).
      Moreover, `decodeDouble_2Int#` performs direct bit-wise operations on the
      IEEE representation which can be replaced by a combination of the
      portable standard C99 `scalbn(3)` and `frexp(3)` functions.
      Differential Revision: https://phabricator.haskell.org/D160
  7. 16 Aug, 2014 3 commits
    • Gabor Greif's avatar
      Revert "Fix typos 'resizze'" · 53cc943a
      Gabor Greif authored
      this is z-encoding (as hvr tells me)
      This reverts commit 425d5178.
    • Gabor Greif's avatar
      Fix typos 'resizze' · 425d5178
      Gabor Greif authored
    • Herbert Valerio Riedel's avatar
      Implement {resize,shrink}MutableByteArray# primops · 246436f1
      Herbert Valerio Riedel authored
      The two new primops with the type-signatures
        resizeMutableByteArray# :: MutableByteArray# s -> Int#
                                -> State# s -> (# State# s, MutableByteArray# s #)
        shrinkMutableByteArray# :: MutableByteArray# s -> Int#
                                -> State# s -> State# s
      allow to resize MutableByteArray#s in-place (when possible), and are useful
      for algorithms where memory is temporarily over-allocated. The motivating
      use-case is for implementing integer backends, where the final target size of
      the result is either N or N+1, and only known after the operation has been
      A future commit will implement a stateful variant of the
      `sizeofMutableByteArray#` operation (see #9447 for details), since now the
      size of a `MutableByteArray#` may change over its lifetime (i.e before
      it gets frozen or GCed).
      Test Plan: ./validate --slow
      Reviewers: ezyang, austin, simonmar
      Reviewed By: austin, simonmar
      Differential Revision: https://phabricator.haskell.org/D133
  8. 30 Jun, 2014 1 commit
    • tibbe's avatar
      Re-add more primops for atomic ops on byte arrays · 4ee4ab01
      tibbe authored
      This is the second attempt to add this functionality. The first
      attempt was reverted in 950fcae4, due
      to register allocator failure on x86. Given how the register
      allocator currently works, we don't have enough registers on x86 to
      support cmpxchg using complicated addressing modes. Instead we fall
      back to a simpler addressing mode on x86.
      Adds the following primops:
       * atomicReadIntArray#
       * atomicWriteIntArray#
       * fetchSubIntArray#
       * fetchOrIntArray#
       * fetchXorIntArray#
       * fetchAndIntArray#
      Makes these pre-existing out-of-line primops inline:
       * fetchAddIntArray#
       * casIntArray#
  9. 26 Jun, 2014 1 commit
  10. 24 Jun, 2014 1 commit
    • tibbe's avatar
      Add more primops for atomic ops on byte arrays · d8abf85f
      tibbe authored
      Add more primops for atomic ops on byte arrays
      Adds the following primops:
       * atomicReadIntArray#
       * atomicWriteIntArray#
       * fetchSubIntArray#
       * fetchOrIntArray#
       * fetchXorIntArray#
       * fetchAndIntArray#
      Makes these pre-existing out-of-line primops inline:
       * fetchAddIntArray#
       * casIntArray#
  11. 29 Mar, 2014 2 commits
    • tibbe's avatar
      Add missing symbols to linker · 838bfb22
      tibbe authored
      The copy array family of primops were moved out-of-line.
    • 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.
  12. 22 Mar, 2014 1 commit
    • tibbe's avatar
      codeGen: inline allocation optimization for clone array primops · 1eece456
      tibbe authored
      The inline allocation version is 69% faster than the out-of-line
      version, when cloning an array of 16 unit elements on a 64-bit
      Comparing the new and the old primop implementations isn't
      straightforward. The old version had a missing heap check that I
      discovered during the development of the new version. Comparing the
      old and the new version would requiring fixing the old version, which
      in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.
      The inline allocation threshold is configurable via
      -fmax-inline-alloc-size which gives the maximum array size, in bytes,
      to allocate inline. The size does not include the closure header size.
      Allowing the same primop to be either inline or out-of-line has some
      implication for how we lay out heap checks. We always place a heap
      check around out-of-line primops, as they may allocate outside of our
      knowledge. However, for the inline primops we only allow allocation
      via the standard means (i.e. virtHp). Since the clone primops might be
      either inline or out-of-line the heap check layout code now consults
      shouldInlinePrimOp to know whether a primop will be inlined.
  13. 17 Feb, 2014 1 commit
  14. 13 Jan, 2014 1 commit
  15. 21 Nov, 2013 1 commit
    • Simon Marlow's avatar
      In the DEBUG rts, track when CAFs are GC'd · e82fa829
      Simon Marlow authored
      This resurrects some old code and makes it work again.  The idea is
      that we want to get an error message if we ever enter a CAF that has
      been GC'd, rather than following its indirection which will likely
      cause a segfault.  Without this patch, these bugs are hard to track
      down in gdb, because the IND_STATIC code overwrites R1 (the pointer to
      the CAF) with its indirectee before jumping into bad memory, so we've
      lost the address of the CAF that got GC'd.
      Some associated refactoring while I was here.
  16. 01 Oct, 2013 2 commits
    • Simon Marlow's avatar
    • Simon Marlow's avatar
      Remove use of R9, and fix associated bugs · 11b5ce55
      Simon Marlow authored
      We were passing the function address to stg_gc_prim_p in R9, which was
      wrong because the call was a high-level call and didn't declare R9 as
      a parameter.  Passing R9 as an argument is the right way, but
      unfortunately that exposed another bug: we were using the same macro
      in some low-level Cmm, where it is illegal to call functions with
      arguments (see Note [syntax of cmm files]).  So we now have low-level
      variants of STK_CHK() and STK_CHK_P() for use in low-level Cmm code.
  17. 23 Sep, 2013 2 commits
  18. 21 Aug, 2013 3 commits
  19. 13 Jul, 2013 1 commit
  20. 10 Jul, 2013 1 commit
  21. 09 Jul, 2013 1 commit
  22. 22 Jun, 2013 1 commit
  23. 15 Jun, 2013 2 commits
    • aljee@hyper.cx's avatar
    • 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.
  24. 18 Feb, 2013 1 commit
  25. 14 Feb, 2013 1 commit
  26. 01 Feb, 2013 1 commit
  27. 30 Jan, 2013 1 commit
    • Ben Gamari's avatar
      STM: Only wake up once · a23661d2
      Ben Gamari authored
      Previously, threads blocked on an STM retry would be sent a wakeup
      message each time an unpark was requested. This could result in the
      accumulation of a large number of wake-up messages, which would slow
      wake-up once the sleeping thread is finally scheduled.
      Here, we introduce a new closure type, STM_AWOKEN, which marks a TSO
      which has been sent a wake-up message, allowing us to send only one
  28. 16 Nov, 2012 1 commit
    • Simon Marlow's avatar
      Add a write barrier for TVAR closures · 6d784c43
      Simon Marlow authored
      This improves GC performance when there are a lot of TVars in the
      heap.  For instance, a TChan with a lot of elements causes a massive
      GC drag without this patch.
      There's more to do - several other STM closure types don't have write
      barriers, so GC performance when there are a lot of threads blocked on
      STM isn't great.  But fixing the problem for TVar is a good start.
  29. 25 Oct, 2012 1 commit
  30. 23 Oct, 2012 1 commit
  31. 15 Oct, 2012 1 commit
    • Duncan Coutts's avatar
      Add a new traceMarker# primop for use in profiling output · a609027d
      Duncan Coutts authored
      In time-based profiling visualisations (e.g. heap profiles and ThreadScope)
      it would be useful to be able to mark particular points in the execution and
      have those points in time marked in the visualisation.
      The traceMarker# primop currently emits an event into the eventlog. In
      principle it could be extended to do something in the heap profiling too.
  32. 08 Oct, 2012 1 commit
    • Simon Marlow's avatar
      Produce new-style Cmm from the Cmm parser · a7c0387d
      Simon Marlow authored
      The main change here is that the Cmm parser now allows high-level cmm
      code with argument-passing and function calls.  For example:
      foo ( gcptr a, bits32 b )
        if (b > 0) {
           // we can make tail calls passing arguments:
           jump stg_ap_0_fast(a);
        return (x,y);
      More details on the new cmm syntax are in Note [Syntax of .cmm files]
      in CmmParse.y.
      The old syntax is still more-or-less supported for those occasional
      code fragments that really need to explicitly manipulate the stack.
      However there are a couple of differences: it is now obligatory to
      give a list of live GlobalRegs on every jump, e.g.
        jump %ENTRY_CODE(Sp(0)) [R1];
      Again, more details in Note [Syntax of .cmm files].
      I have rewritten most of the .cmm files in the RTS into the new
      syntax, except for AutoApply.cmm which is generated by the genapply
      program: this file could be generated in the new syntax instead and
      would probably be better off for it, but I ran out of enthusiasm.
      Some other changes in this batch:
       - The PrimOp calling convention is gone, primops now use the ordinary
         NativeNodeCall convention.  This means that primops and "foreign
         import prim" code must be written in high-level cmm, but they can
         now take more than 10 arguments.
       - CmmSink now does constant-folding (should fix #7219)
       - .cmm files now go through the cmmPipeline, and as a result we
         generate better code in many cases.  All the object files generated
         for the RTS .cmm files are now smaller.  Performance should be
         better too, but I haven't measured it yet.
       - RET_DYN frames are removed from the RTS, lots of code goes away
       - we now have some more canned GC points to cover unboxed-tuples with
         2-4 pointers, which will reduce code size a little.