Skip to content
  • Daniel Gröber (dxld)'s avatar
    Zero out pinned block alignment slop when profiling · 41230e26
    Daniel Gröber (dxld) authored and Marge Bot's avatar Marge Bot committed
    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. However for the new root profiler 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, 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
    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.
    
    Metric Decrease:
        T7257
        haddock.Cabal
        haddock.base
    41230e26