1. 19 Nov, 2019 13 commits
    • Ben Gamari's avatar
      nonmoving: Drop redundant write barrier on stack underflow · 098d5017
      Ben Gamari authored
      Previously we would push stack-carried return values to the new stack on
      a stack overflow. While the precise reasoning for this barrier is
      unfortunately lost to history, in hindsight I suspect it was prompted by
      a missing barrier elsewhere (that has been since fixed).
      
      Moreover, there the redundant barrier is actively harmful: the stack may
      contain non-pointer values; blindly pushing these to the mark queue will
      result in a crash. This is precisely what happened in the `stack003`
      test. However, because of a (now fixed) deficiency in the test this
      crash did not trigger on amd64.
      098d5017
    • Ben Gamari's avatar
      testsuite: Increase width of stack003 test · a7571a74
      Ben Gamari authored
      Previously the returned tuple seemed to fit in registers on amd64. This
      meant that non-moving collector bug would cause the test to fail on i386
      yet not amd64.
      a7571a74
    • Ben Gamari's avatar
      nonmoving: Fix handling on large object marking on 32-bit · eb7b233a
      Ben Gamari authored
      Previously we would reset the pointer pointing to the object to be
      marked to the beginning of the block when marking a large object. This
      did no harm on 64-bit but on 32-bit it broke, e.g. `arr020`, since we
      align pinned ByteArray allocations such that the payload is 8
      byte-aligned. This means that the object might not begin at the
      beginning of the block.,
      eb7b233a
    • Ben Gamari's avatar
      nonmoving: Rework mark queue representation · 097f8072
      Ben Gamari authored
      The previous representation needlessly limited the array length to
      16-bits on 32-bit platforms.
      097f8072
    • Ben Gamari's avatar
      nonmoving: Fix incorrect masking in mark queue type test · deed8e31
      Ben Gamari authored
      We were using TAG_BITS instead of TAG_MASK. This happened to work on
      64-bit platforms where TAG_BITS==3 since we only use tag values 0 and
      3. However, this broken on 32-bit platforms where TAG_BITS==2.
      deed8e31
    • Ben Gamari's avatar
      nonmoving: Use correct info table pointer accessor · c819c0e4
      Ben Gamari authored
      Previously we used INFO_PTR_TO_STRUCT instead of
      THUNK_INFO_PTR_TO_STRUCT when looking at a thunk. These two happen to be
      equivalent on 64-bit architectures due to alignment considerations
      however they are different on 32-bit platforms. This lead to #17487.
      
      To fix this we also employ a small optimization: there is only one thunk
      of type WHITEHOLE (namely stg_WHITEHOLE_info). Consequently, we can just
      use a plain pointer comparison instead of testing against info->type.
      c819c0e4
    • Ben Gamari's avatar
      rts: Add missing include of SymbolExtras.h · 0418c38d
      Ben Gamari authored
      This broke the Windows build.
      0418c38d
    • Ben Gamari's avatar
      Properly account for libdw paths in make build system · 2b27cc16
      Ben Gamari authored
      Should finally fix #17255.
      2b27cc16
    • Ömer Sinan Ağacan's avatar
      Packages.hs: use O(n*log(n)) ordNub instead of O(n*n) nub · cd40e12a
      Ömer Sinan Ağacan authored
      As reported in #8173 in some environments package lists can get quite
      long, so we use more efficient ordNub instead of nub on package lists.
      cd40e12a
    • vdukhovni's avatar
      Enable USE_PTHREAD_FOR_ITIMER also on FreeBSD · ec8a463d
      vdukhovni authored
      If using a pthread instead of a timer signal is more reliable, and
      has no known drawbacks, then FreeBSD is also capable of supporting
      this mode of operation (tested on FreeBSD 12 with GHC 8.8.1, but
      no reason why it would not also work on FreeBSD 11 or GHC 8.6).
      
      Proposed by Kevin Zhang in:
      
          https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241849
      ec8a463d
    • Ben Gamari's avatar
      Give seq a more precise type and remove magic · 08d595c0
      Ben Gamari authored
      `GHC.Prim.seq` previously had the rather plain type:
      
          seq :: forall a b. a -> b -> b
      
      However, it also had a special typing rule to applications
      where `b` is not of kind `Type`.
      
      Issue #17440 noted that levity polymorphism allows us to rather give
      it the more precise type:
      
          seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
      
      This allows us to remove the special typing rule that we previously
      required to allow applications on unlifted arguments. T9404 contains a
      non-Type application of `seq` which should verify that this works as
      expected.
      
      Closes #17440.
      08d595c0
    • Ben Gamari's avatar
      desugar: Drop stale Note [Matching seqId] · a8adb5b4
      Ben Gamari authored
      The need for this note vanished in
      eae703aa.
      a8adb5b4
    • Alex D's avatar
      Optimize MonadUnique instances based on IO (#16843) · 88013b78
      Alex D authored
      Metric Decrease:
          T14683
      88013b78
  2. 17 Nov, 2019 10 commits
  3. 15 Nov, 2019 6 commits
  4. 14 Nov, 2019 1 commit
  5. 13 Nov, 2019 8 commits
  6. 12 Nov, 2019 1 commit
    • Alp Mestanogullari's avatar
      testsuite: don't collect compiler stats in collect_runtime_residency · 643d42fc
      Alp Mestanogullari authored
      We instead want to collect the runtime stats (with collect_stats, instead of
      collect_compiler_stats).
      
      This should fix a number of perf tests failures we have been seeing, where
      we suddenly started measuring metrics we didn't intend to measure, which
      tend to fall outside of the acceptance window.
      
      Metric Decrease:
          lazy-bs-alloc
          T3586
      
      Metric Increase:
          space_leak_001
          T4801
          T5835
          T12791
      643d42fc
  7. 11 Nov, 2019 1 commit
    • Alp Mestanogullari's avatar
      ci: push perf test metrics even when the testsuite doesn't pass · f8ec32d7
      Alp Mestanogullari authored
      The corresponding commit might introduce a regression on a perf test, in which
      case we certainly want to record it. The testsuite might also fail because
      of a test unrelated to performance, in which case we want to record that the
      perf test results were good.
      
      Either way, we likely want to record them under all circumstances but
      we don't without this patch.
      
      Metric Decrease:
          T3586
      
      Metric Increase:
          lazy-bs-alloc
      f8ec32d7