1. 11 Dec, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · c3c70244
      Moritz Angermann authored
      Summary:
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      This is a reboot of D2575, that should hopefully not exhibit the same
      windows build issues.
      
      Reviewers: Phyx, simonmar, goldfire, bgamari, austin, hvr, erikd
      
      Reviewed By: Phyx, simonmar, bgamari
      
      Subscribers: mpickering, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2773
      c3c70244
  2. 30 Nov, 2016 1 commit
  3. 29 Nov, 2016 1 commit
    • Moritz Angermann's avatar
      Make globals use sharedCAF · 6f7ed1e5
      Moritz Angermann authored
      The use of globals is quite painful when multiple rts are loaded, e.g.
      when plugins are loaded, which bring in a second rts. The sharedCAF
      appraoch was employed for the FastStringTable; I've taken the libery
      to extend this to the other globals I could find.
      
      Reviewers: rwbarton, simonmar, austin, hvr, erikd, bgamari
      
      Reviewed By: simonmar, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2575
      6f7ed1e5
  4. 12 Sep, 2016 1 commit
    • Simon Marlow's avatar
      Add hs_try_putmvar() · 454033b5
      Simon Marlow authored
      Summary:
      This is a fast, non-blocking, asynchronous, interface to tryPutMVar that
      can be called from C/C++.
      
      It's useful for callback-based C/C++ APIs: the idea is that the callback
      invokes hs_try_putmvar(), and the Haskell code waits for the callback to
      run by blocking in takeMVar.
      
      The callback doesn't block - this is often a requirement of
      callback-based APIs.  The callback wakes up the Haskell thread with
      minimal overhead and no unnecessary context-switches.
      
      There are a couple of benchmarks in
      testsuite/tests/concurrent/should_run.  Some example results comparing
      hs_try_putmvar() with using a standard foreign export:
      
          ./hs_try_putmvar003 1 64 16 100 +RTS -s -N4     0.49s
          ./hs_try_putmvar003 2 64 16 100 +RTS -s -N4     2.30s
      
      hs_try_putmvar() is 4x faster for this workload (see the source for
      hs_try_putmvar003.hs for details of the workload).
      
      An alternative solution is to use the IO Manager for this.  We've tried
      it, but there are problems with that approach:
      * Need to create a new file descriptor for each callback
      * The IO Manger thread(s) become a bottleneck
      * More potential for things to go wrong, e.g. throwing an exception in
        an IO Manager callback kills the IO Manager thread.
      
      Test Plan: validate; new unit tests
      
      Reviewers: niteria, erikd, ezyang, bgamari, austin, hvr
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2501
      454033b5
  5. 06 Jun, 2016 1 commit
    • seraphime's avatar
      Add @since annotations to base instances · a90085bd
      seraphime authored
      Add @since annotations to instances in `base`.
      
      Test Plan:
       * ./validate  # some commets shouldn't break the build
       * review the annotations for absurdities.
      
      Reviewers: ekmett, goldfire, RyanGlScott, austin, hvr, bgamari
      
      Reviewed By: RyanGlScott, hvr, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2277
      
      GHC Trac Issues: #11767
      a90085bd
  6. 01 Jan, 2016 1 commit
    • Herbert Valerio Riedel's avatar
      Canonicalise `MonadPlus` instances · dafeb51f
      Herbert Valerio Riedel authored
      This refactoring exploits the fact that since AMP, in most cases,
      `instance MonadPlus` can be automatically derived from the respective
      `Alternative` instance.  This is because `MonadPlus`'s default method
      implementations are fully defined in terms of `Alternative(empty, (<>))`.
      dafeb51f
  7. 23 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Allow CallStacks to be frozen · 380b25ea
      Eric Seidel authored
      This introduces "freezing," an operation which prevents further
      locations from being appended to a CallStack.  Library authors may want
      to prevent CallStacks from exposing implementation details, as a matter
      of hygiene. For example, in
      
      ```
      head [] = error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      including the call-site of `error` in `head` is not strictly necessary
      as the error message already specifies clearly where the error came
      from.
      
      So we add a function `freezeCallStack` that wraps an existing CallStack,
      preventing further call-sites from being pushed onto it. In other words,
      
      ```
      pushCallStack callSite (freezeCallStack callStack) = freezeCallStack callStack
      ```
      
      Now we can define `head` to not produce a CallStack at all
      
      ```
      head [] =
        let ?callStack = freezeCallStack emptyCallStack
        in error "head: empty list"
      
      ghci> head []
      *** Exception: head: empty list
      CallStack (from implicit params):
        error, called at ...
      ```
      
      ---
      
      1. We add the `freezeCallStack` and `emptyCallStack` and update the
         definition of `CallStack` to support this functionality.
      
      2. We add `errorWithoutStackTrace`, a variant of `error` that does not
         produce a stack trace, using this feature. I think this is a sensible
         wrapper function to provide in case users want it.
      
      3. We replace uses of `error` in base with `errorWithoutStackTrace`. The
         rationale is that base does not export any functions that use CallStacks
         (except for `error` and `undefined`) so there's no way for the stack
         traces (from Implicit CallStacks) to include user-defined functions.
         They'll only contain the call to `error` itself. As base already has a
         good habit of providing useful error messages that name the triggering
         function, the stack trace really just adds noise to the error. (I don't
         have a strong opinion on whether we should include this third commit,
         but the change was very mechanical so I thought I'd include it anyway in
         case there's interest)
      
      4. Updates tests in `array` and `stm` submodules
      
      Test Plan: ./validate, new test is T11049
      
      Reviewers: simonpj, nomeata, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1628
      
      GHC Trac Issues: #11049
      380b25ea
  8. 16 Dec, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Start using `-W` instead of `-f(no-)warn` in some places · 437ebdda
      Herbert Valerio Riedel authored
      This replaces some occurences of `-f(no-)warn` with the new `-W`-aliases
      introduced via 2206fa8c / #11218, in cases which are guaranteed
      to be invoked with recent enough GHC (i.e. the stage1+ GHC).
      
      After this commit, mostly the compiler and the testsuite remain using
      `-f(wo-)warn...` because the compiler needs to be bootstrappable with
      older GHCs, while for the testsuite it's convenient to be able to quickly
      compare the behavior to older GHCs (which may not support the new flags yet).
      
      The compiler-part can be updated to use the new flags once GHC 8.3 development
      starts.
      
      Reviewed By: quchen
      
      Differential Revision: https://phabricator.haskell.org/D1637
      437ebdda
  9. 12 Oct, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      base: MRP-refactoring of AMP instances · e737a512
      Herbert Valerio Riedel authored
      This refactors `(>>)`/`(*>)`/`return`/`pure` methods into normal form.
      
      The redundant explicit `return` method definitions are dropped
      altogether.
      
      The explicit `(>>) = (*>)` definitions can't be removed yet, as
      the default implementation of `(>>)` is still in terms of `(*>)`
      (even though that should have been changed according to the AMP but
      wasn't -- see note in GHC.Base for details why this had to be postponed)
      
      A nofib comparision shows this refactoring to result in minor runtime
      improvements (unless those are within normal measurement fluctuations):
      
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
        -------------------------------------------------------------------------
                  Min          -0.0%     -0.0%     -1.6%     -3.9%     -1.1%
                  Max          -0.0%     +0.0%     +0.5%     +0.5%      0.0%
        Geometric Mean         -0.0%     -0.0%     -0.4%     -0.5%     -0.0%
      
      Full `nofib` report at https://phabricator.haskell.org/P68
      
      Reviewers: quchen, alanz, austin, #core_libraries_committee, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1316
      e737a512
  10. 23 Sep, 2015 2 commits
  11. 22 Sep, 2015 1 commit
  12. 14 Mar, 2015 1 commit
  13. 07 Mar, 2015 1 commit
  14. 16 Dec, 2014 1 commit
  15. 24 Nov, 2014 1 commit
  16. 12 Nov, 2014 1 commit
  17. 08 Nov, 2014 1 commit
  18. 18 Sep, 2014 1 commit
  19. 09 Sep, 2014 1 commit
    • Austin Seipp's avatar
      Make Applicative a superclass of Monad · d94de872
      Austin Seipp authored
      Summary:
      This includes pretty much all the changes needed to make `Applicative`
      a superclass of `Monad` finally. There's mostly reshuffling in the
      interests of avoid orphans and boot files, but luckily we can resolve
      all of them, pretty much. The only catch was that
      Alternative/MonadPlus also had to go into Prelude to avoid this.
      
      As a result, we must update the hsc2hs and haddock submodules.
      Signed-off-by: default avatarAustin Seipp <austin@well-typed.com>
      
      Test Plan: Build things, they might not explode horribly.
      
      Reviewers: hvr, simonmar
      
      Subscribers: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D13
      d94de872
  20. 28 Jul, 2014 1 commit
    • Jost Berthold's avatar
      use GHC-7.8.3's values for thread block reason (fixes #9333) · 4ee8c273
      Jost Berthold authored
      Summary:
      For now, BlockedOnMVar and BlockedOnMVarRead are not distinguished.
      Making the distinction would mean to change an exported datatype
      (API change). Code for this change is included but commented out.
      
      The patch adds a test for the threadstatus, which retrieves status
      BlockedOnMVar for two threads blocked on writing and reading an MVar.
      
      Test Plan: ran validate, including the new test
      
      Reviewers: simonmar, austin, ezyang
      
      Reviewed By: austin, ezyang
      
      Subscribers: phaskell, simonmar, relrod, carter
      
      Differential Revision: https://phabricator.haskell.org/D83
      4ee8c273
  21. 10 Jul, 2014 1 commit
  22. 04 May, 2014 1 commit
  23. 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
  24. 25 Oct, 2013 1 commit
  25. 12 Oct, 2013 1 commit
  26. 28 Sep, 2013 1 commit
  27. 22 Sep, 2013 2 commits
  28. 21 Sep, 2013 1 commit
  29. 18 Sep, 2013 1 commit
  30. 17 Sep, 2013 2 commits
  31. 08 Sep, 2013 2 commits
  32. 16 Aug, 2013 1 commit
  33. 14 Aug, 2013 1 commit
  34. 09 Jul, 2013 1 commit
  35. 16 Feb, 2013 2 commits