Skip to content

Zero out pinned block alignment slop when profiling

Daniel Gröber (dxld) requested to merge DanielG/ghc:prof-zero-slop into master

The heap profiler currently cannot traverse pinned blocks because of alignment slop. This used to just be a minor annoyance as the whole block is accounted into a special cost center rather than the respective object's CCS, cf. #7275 (closed). However for the new root profiler (!1433 (closed)) we would like to be able to visit every closure on the heap. We need to do this so we can get rid of the current 'flip' bit hack in the heap traversal code.

Since info pointers are always non-zero we can in principle skip all the slop in the profiler if we can rely on it being zeroed. This assumption caused problems in the past though, commit a586b33f ("rts: Correct handling of LARGE ARR_WORDS in LDV profiler"), part of !1118 (closed), tried to use the same trick for BF_LARGE objects but neglected to take into account that shrink*Array# functions don't ensure that slop is zeroed when not compiling with profiling.

Later, commit 0c114c65 ("Handle large ARR_WORDS in heap census (fix #17572 (closed))") removed the slop skipping trick again. We're learning from this as we will only be assuming slop is zeroed when profiling is on.

This commit also reduces the ammount of slop we introduce in the first place by calculating the needed alignment before doing the allocation for small objects where we know the next available address. For large objects we don't know how much alignment we'll have to do yet since those details are hidden behind the allocateMightFail function so there we continue to allocate the maximum additional words we'll need to do the alignment.

So we don't have to duplicate all this logic in the cmm code we pull it into the RTS allocatePinned function instead.


This is part of !1433 (closed) pulled out into a speperate PR for more thorough review since it touches some primops.


  • are either individually buildable or squashed
  • have commit messages which describe what they do
  • have added source comments describing your change. For larger changes you likely should add a [Note][notes] and cross-reference it from the relevant places.
  • add a testcase to the testsuite.
Edited by Daniel Gröber (dxld)

Merge request reports