[Git][ghc/ghc][wip/T7275] rts: Zero shrunk array slop in vanilla RTS

Ben Gamari gitlab at gitlab.haskell.org
Thu Dec 10 14:36:39 UTC 2020



Ben Gamari pushed to branch wip/T7275 at Glasgow Haskell Compiler / GHC


Commits:
aed29739 by Ben Gamari at 2020-12-10T09:36:33-05:00
rts: Zero shrunk array slop in vanilla RTS

But only when profiling or DEBUG are enabled.

Fixes #17572 and #9666.

- - - - -


3 changed files:

- includes/Cmm.h
- rts/sm/Storage.c
- utils/deriveConstants/Main.hs


Changes:

=====================================
includes/Cmm.h
=====================================
@@ -630,7 +630,11 @@
 #else
 #define OVERWRITING_CLOSURE_SIZE(c, size) /* nothing */
 #define OVERWRITING_CLOSURE(c) /* nothing */
-#define OVERWRITING_CLOSURE_MUTABLE(c, off) /* nothing */
+/* This is used to zero slop after shrunk arrays. It is important that we do
+ * this whenever profiling is enabled as described in Note [slop on the heap]
+ * in Storage.c. */
+#define OVERWRITING_CLOSURE_MUTABLE(c, off) \
+  if (RtsFlags_ProfFlags_doHeapProfile != 0) { foreign "C" overwritingMutableClosureOfs(c "ptr", off); }
 #endif
 
 // Memory barriers.


=====================================
rts/sm/Storage.c
=====================================
@@ -953,14 +953,19 @@ accountAllocation(Capability *cap, W_ n)
  * profiler, see Note [skipping slop in the heap profiler].
  *
  * In general we zero:
+ *
  *  - Pinned object alignment slop, see MEMSET_SLOP_W in allocatePinned.
  *  - Large object alignment slop, see MEMSET_SLOP_W in allocatePinned.
- * This is necessary even in the vanilla RTS since the user may trigger a heap
- * census via +RTS -hT even when not linking against the profiled RTS.
- *
- * Only when profiling we zero:
  *  - Shrunk array slop, see OVERWRITING_CLOSURE_MUTABLE.
  *
+ * Note that this is necessary even in the vanilla (e.g. non-profiling) RTS
+ * since the user may trigger a heap census via +RTS -hT, which can be used
+ * even when not linking against the profiled RTS. Failing to zero slop
+ * due to array shrinking has resulted in a few nasty bugs (#17572, #9666).
+ * However, since array shrink may result in large amounts of slop (unlike
+ * alignment), we take care to only zero such slop when heap profiling or DEBUG
+ * are enabled.
+ *
  * When performing LDV profiling or using a (single threaded) debug RTS we zero
  * slop even when overwriting immutable closures, see Note [zeroing slop when
  * overwriting closures].


=====================================
utils/deriveConstants/Main.hs
=====================================
@@ -561,6 +561,8 @@ wanteds os = concat
           ,structField  C "StgCompactNFDataBlock" "owner"
           ,structField  C "StgCompactNFDataBlock" "next"
 
+          ,structField_ C "RtsFlags_ProfFlags_doHeapProfile"
+                          "RTS_FLAGS" "ProfFlags.doHeapProfile"
           ,structField_ C "RtsFlags_ProfFlags_showCCSOnException"
                           "RTS_FLAGS" "ProfFlags.showCCSOnException"
           ,structField_ C "RtsFlags_DebugFlags_apply"



View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/aed297394b7d57aaced800e5341bc9a0a5312d26

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/aed297394b7d57aaced800e5341bc9a0a5312d26
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20201210/0f3c18b9/attachment-0001.html>


More information about the ghc-commits mailing list