Skip to content

hadrian's ticky_ghc transformer doesn't build `containers` (and other boot libs) with -ticky

Today I was wondering why I was missing 500MB of IntMap.$winsert allocation in a ticky profile compared to another. It turned out that I had used an outdated alias (that predates the ticky_ghc flavour transformer) for compiling a ticky build in the checkout that showed the 500MB, but immediately I wondered: Why didn't the 500MB show up in the other profile? Although it's in containers, not GHC, it's a substantial bulk of allocation that might increase if an optimisation goes wrong. I'd rather see it in the ticky profiles.

So I dug in hadrian and found

enableTickyGhc :: Flavour -> Flavour
enableTickyGhc =
    addArgs $ foldMap enableTickyFor [ghc, compiler, base]
  where
    enableTickyFor pkg = stage1 ? package pkg ? mconcat
      [ builder (Ghc CompileHs) ? ticky
      , builder (Ghc LinkHs) ? ticky
      ]
    ticky = mconcat
      [ arg "-ticky"
      , arg "-ticky-allocd"
      -- You generally need STG dumps to interpret ticky profiles
      , arg "-ddump-to-file"
      , arg "-ddump-stg-final"
      ]

Why only do this for ghc, compiler and base? At least do it for containers, too. Better just remove the list and say

enableTickyGhc :: Flavour -> Flavour
enableTickyGhc =
    addArgs $ stage1 ? mconcat
      [ builder (Ghc CompileHs) ? ticky
      , builder (Ghc LinkHs) ? ticky
      ]
  where
    ticky = mconcat
      [ arg "-ticky"
      , arg "-ticky-allocd"
      -- You generally need STG dumps to interpret ticky profiles
      , arg "-ddump-to-file"
      , arg "-ddump-stg-final"
      ]
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information