1. 21 Aug, 2009 3 commits
    • simonpj@microsoft.com's avatar
      Another tiny tidy-up to RnPat · 8ec97816
      simonpj@microsoft.com authored
    • simonpj@microsoft.com's avatar
      Fix Trac #3437: strictness of specialised functions · ef5376d5
      simonpj@microsoft.com authored
      'lilac' helpful pin-pointed a space leak that was due to a specialised
      function being insufficiently strict.  Here's the new comment in SpecConstr:
      Note [Transfer strictness]
      We must transfer strictness information from the original function to
      the specialised one.  Suppose, for example
        f has strictness     SS
              and a RULE     f (a:as) b = f_spec a as b
      Now we want f_spec to have strictess  LLS, otherwise we'll use call-by-need
      when calling f_spec instead of call-by-value.  And that can result in 
      unbounded worsening in space (cf the classic foldl vs foldl')
      See Trac #3437 for a good example.
      The function calcSpecStrictness performs the calculation.
    • simonpj@microsoft.com's avatar
      Wibbles to field-label puns · f7df28a4
      simonpj@microsoft.com authored
  2. 20 Aug, 2009 15 commits
  3. 19 Aug, 2009 5 commits
  4. 20 Aug, 2009 1 commit
  5. 19 Aug, 2009 5 commits
  6. 18 Aug, 2009 1 commit
  7. 19 Aug, 2009 3 commits
  8. 18 Aug, 2009 2 commits
    • Thomas Schilling's avatar
      Remove the lock around NameCache for readBinIface. · cadba810
      Thomas Schilling authored
      Turns out using atomic update instead of a full-blown lock was easier
      than I thought.  It should also be safe in the case where we
      concurrently read the same interface file.  Whichever thread loses the
      race will simply find that all of the names are already defined and
      will have no effect on the name cache.
    • Simon Marlow's avatar
      Fix #3429: a tricky race condition · c5cafbcc
      Simon Marlow authored
      There were two bugs, and had it not been for the first one we would
      not have noticed the second one, so this is quite fortunate.
      The first bug is in stg_unblockAsyncExceptionszh_ret, when we found a
      pending exception to raise, but don't end up raising it, there was a
      missing adjustment to the stack pointer.  
      The second bug was that this case was actually happening at all: it
      ought to be incredibly rare, because the pending exception thread
      would have to be killed between us finding it and attempting to raise
      the exception.  This made me suspicious.  It turned out that there was
      a race condition on the tso->flags field; multiple threads were
      updating this bitmask field non-atomically (one of the bits is the
      dirty-bit for the generational GC).  The fix is to move the dirty bit
      into its own field of the TSO, making the TSO one word larger (sadly).
  9. 17 Aug, 2009 3 commits
  10. 06 Aug, 2009 2 commits