1. 28 Mar, 2017 1 commit
  2. 01 Mar, 2017 1 commit
    • David Feuer's avatar
      Change catch# demand signature · 701256df
      David Feuer authored
      * Give `catch#` a lazy demand signature, to make it more honest.
      
      * Make `catchException` and `catchAny` force their arguments so they
      actually behave as advertised.
      
      * Use `catch` rather than `catchException` in `forkIO`, `forkOn`, and
      `forkOS` to avoid losing exceptions.
      
      Fixes #13330
      
      Reviewers: rwbarton, simonpj, simonmar, bgamari, hvr, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D3244
      701256df
  3. 22 Jan, 2017 1 commit
    • thomie's avatar
      Remove clean_cmd and extra_clean usage from .T files · 5d38fb69
      thomie authored
      The `clean_cmd` and `extra_clean` setup functions don't do anything.
      Remove them from .T files.
      
      Created using https://github.com/thomie/refactor-ghc-testsuite. This
      diff is a test for the .T-file parser/processor/pretty-printer in that
      repository.
      
          find . -name '*.T' -exec ~/refactor-ghc-testsuite/Main "{}" \;
      
      Tests containing inline comments or multiline strings are not modified.
      
      Preparation for #12223.
      
      Test Plan: Harbormaster
      
      Reviewers: austin, hvr, simonmar, mpickering, bgamari
      
      Reviewed By: mpickering
      
      Subscribers: mpickering
      
      Differential Revision: https://phabricator.haskell.org/D3000
      
      GHC Trac Issues: #12223
      5d38fb69
  4. 01 Dec, 2016 1 commit
  5. 07 Nov, 2016 1 commit
    • Simon Marlow's avatar
      Fix hs_try_putmvar003 (#12800) · 91f9e138
      Simon Marlow authored
      Summary:
      There was a race condition on some shared data when creating the
      callback thread.
      
      I couldn't repro the issue without inserting a dummy usleep(100), but
      it's definitely a bug.
      
      Test Plan: validate
      
      Reviewers: bgamari, austin, erikd
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2678
      
      GHC Trac Issues: #12800
      91f9e138
  6. 22 Oct, 2016 2 commits
    • Matthew Pickering's avatar
      Skip T5611 on OSX as it fails non-deterministically. · a662f46c
      Matthew Pickering authored
      Reviewers: austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2622
      
      GHC Trac Issues: #12751
      a662f46c
    • Simon Marlow's avatar
      Fix failure in setnumcapabilities001 (#12728) · acc98510
      Simon Marlow authored
      The value of enabled_capabilities can change across a call to
      requestSync(), and we were erroneously using an old value, causing
      things to go wrong later.  It manifested as an assertion failure, I'm
      not sure whether there are worse consequences or not, but we should
      get this fix into 8.0.2 anyway.
      
      The failure didn't happen for me because it only shows up on machines
      with fewer than 4 processors, due to the new logic to enable -qn
      automatically.  I've bumped the test parameter 8 to make it more
      likely to exercise that code.
      
      Test Plan: Ran setnumcapabilities001 many times
      
      Reviewers: niteria, austin, erikd, rwbarton, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2617
      
      GHC Trac Issues: #12728
      acc98510
  7. 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
  8. 29 Jun, 2016 1 commit
    • thomie's avatar
      Testsuite: use ignore_stderr/stdout instead of ignore_output · 1084d375
      thomie authored
      The problem with ignore_output is that it hides errors for WAY=ghci.
      GHCi always returns with exit code 0 (unless it is broken itself).
      
      For example: ghci015 must have been failing with compile errors for
      years, but we didn't notice because all output was ignored.
      
      Therefore, replace all uses of ignore_output with either ignore_stderr
      or ignore_stdout. In some cases I opted for adding the expected output.
      
      Update submodule hpc and stm.
      
      Reviewed by: simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2367
      1084d375
  9. 20 Jun, 2016 1 commit
  10. 10 Jun, 2016 1 commit
    • Simon Marlow's avatar
      NUMA support · 9e5ea67e
      Simon Marlow authored
      Summary:
      The aim here is to reduce the number of remote memory accesses on
      systems with a NUMA memory architecture, typically multi-socket servers.
      
      Linux provides a NUMA API for doing two things:
      * Allocating memory local to a particular node
      * Binding a thread to a particular node
      
      When given the +RTS --numa flag, the runtime will
      * Determine the number of NUMA nodes (N) by querying the OS
      * Assign capabilities to nodes, so cap C is on node C%N
      * Bind worker threads on a capability to the correct node
      * Keep a separate free lists in the block layer for each node
      * Allocate the nursery for a capability from node-local memory
      * Allocate blocks in the GC from node-local memory
      
      For example, using nofib/parallel/queens on a 24-core 2-socket machine:
      
      ```
      $ ./Main 15 +RTS -N24 -s -A64m
        Total   time  173.960s  (  7.467s elapsed)
      
      $ ./Main 15 +RTS -N24 -s -A64m --numa
        Total   time  150.836s  (  6.423s elapsed)
      ```
      
      The biggest win here is expected to be allocating from node-local
      memory, so that means programs using a large -A value (as here).
      
      According to perf, on this program the number of remote memory accesses
      were reduced by more than 50% by using `--numa`.
      
      Test Plan:
      * validate
      * There's a new flag --debug-numa=<n> that pretends to do NUMA without
        actually making the OS calls, which is useful for testing the code
        on non-NUMA systems.
      * TODO: I need to add some unit tests
      
      Reviewers: erikd, austin, rwbarton, ezyang, bgamari, hvr, niteria
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2199
      9e5ea67e
  11. 11 May, 2016 2 commits
  12. 04 Apr, 2016 1 commit
    • Eric Seidel's avatar
      Don't infer CallStacks · 7407a66d
      Eric Seidel authored
      We originally wanted CallStacks to be opt-in, but dealing with let
      binders complicated things, forcing us to infer CallStacks. It turns
      out that the inference is actually unnecessary though, we can let the
      wanted CallStacks bubble up to the outer context by refusing to
      quantify over them. Eventually they'll be solved from a given CallStack
      or defaulted to the empty CallStack if they reach the top.
      
      So this patch prevents GHC from quantifying over CallStacks, getting us
      back to the original plan. There's a small ugliness to do with
      PartialTypeSignatures, if the partial theta contains a CallStack
      constraint, we *do* want to quantify over the CallStack; the user asked
      us to!
      
      Note that this means that
      
        foo :: _ => CallStack
        foo = getCallStack callStack
      
      will be an *empty* CallStack, since we won't infer a CallStack for the
      hole in the theta. I think this is the right move though, since we want
      CallStacks to be opt-in. One can always write
      
        foo :: (HasCallStack, _) => CallStack
        foo = getCallStack callStack
      
      to get the CallStack and still have GHC infer the rest of the theta.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: bitemyapp, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1912
      
      GHC Trac Issues: #11573
      7407a66d
  13. 25 Feb, 2016 2 commits
  14. 23 Feb, 2016 1 commit
  15. 11 Feb, 2016 1 commit
  16. 26 Jan, 2016 1 commit
  17. 17 Dec, 2015 1 commit
  18. 12 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
  19. 13 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make 'error' include the CCS call stack when profiled · 8988be85
      Simon Marlow authored
      Summary:
      The idea here is that this gives a more detailed stack trace in two
      cases:
      
      1. With `-prof` and `-fprof-auto`
      2. In GHCi (see #11047)
      
      Example, with an error inserted in nofib/shootout/binary-trees:
      
      ```
      $ ./Main 3
      Main: z
      CallStack (from ImplicitParams):
        error, called at Main.hs:67:29 in main:Main
      CallStack (from -prof):
        Main.check' (Main.hs:(67,1)-(68,82))
        Main.check (Main.hs:63:1-21)
        Main.stretch (Main.hs:32:35-57)
        Main.main.c (Main.hs:32:9-57)
        Main.main (Main.hs:(27,1)-(43,42))
        Main.CAF (<entire-module>)
      ```
      
      This doesn't quite obsolete +RTS -xc, which also attempts to display
      more information in the case when the error is in a CAF, but I'm
      exploring other solutions to that.
      
      Includes submodule updates.
      
      Test Plan: validate
      
      Reviewers: simonpj, ezyang, gridaphobe, bgamari, hvr, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1426
      8988be85
  20. 30 Oct, 2015 1 commit
  21. 22 Sep, 2015 1 commit
  22. 09 Sep, 2015 1 commit
  23. 02 Sep, 2015 2 commits
  24. 21 Jul, 2015 1 commit
  25. 18 Jul, 2015 1 commit
  26. 13 Jul, 2015 1 commit
  27. 26 Jun, 2015 1 commit
    • Simon Marlow's avatar
      Fix deadlock (#10545) · 111ba4be
      Simon Marlow authored
      yieldCapability() was not prepared to be called by a Task that is not
      either a worker or a bound Task.  This could happen if we ended up in
      yieldCapability via this call stack:
      
      performGC()
      scheduleDoGC()
      requestSync()
      yieldCapability()
      
      and there were a few other ways this could happen via requestSync.
      The fix is to handle this case in yieldCapability(): when the Task is
      not a worker or a bound Task, we put it on the returning_workers
      queue, where it will be woken up again.
      
      Summary of changes:
      
      * `yieldCapability`: factored out subroutine waitForWorkerCapability`
      * `waitForReturnCapability` renamed to `waitForCapability`, and
        factored out subroutine `waitForReturnCapability`
      * `releaseCapabilityAndQueue` worker renamed to `enqueueWorker`, does
        not take a lock and no longer tests if `!isBoundTask()`
      * `yieldCapability` adjusted for refactorings, only change in behavior
        is when it is not a worker or bound task.
      
      Test Plan:
      * new test concurrent/should_run/performGC
      * validate
      
      Reviewers: niteria, austin, ezyang, bgamari
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D997
      
      GHC Trac Issues: #10545
      111ba4be
  28. 19 Jun, 2015 1 commit
  29. 12 Jun, 2015 1 commit
  30. 09 Jun, 2015 1 commit
  31. 12 Nov, 2014 2 commits
  32. 07 Oct, 2014 1 commit
  33. 28 Aug, 2014 1 commit
  34. 19 Aug, 2014 2 commits