GHC State Hack: Reducing Allocation Costs in Low-Traffic Workloads

Impact of Disabling the State Hack

Disabling the state hack via -fno-state-hack does not consistently reduce total bytes allocated across all low-traffic scenarios in GHC 9.0+. While it can lower allocations by preventing the creation of certain closures and enabling let-binding floating, the result is highly dependent on the specific code patterns and the effectiveness of GHC's strictness analysis in a given module.

The Trade-off: Allocation vs. Execution Time

The state hack assumes that State# tokens are used linearly, which allows GHC to perform aggressive inlining and eta-expansion. When you disable this heuristic, you shift the performance profile:

• Allocation: Potential reduction in closure creation. In low-traffic workloads where memory overhead and subsequent GC pressure are primary cost drivers, this can lead to a more stable memory footprint.
• Execution Time: Potential increase in runtime. By limiting the compiler's ability to inline and expand functions, you may introduce additional function call overhead and reduce the effectiveness of other optimizations.

Interaction with -fspecialise-aggressively

Using -fno-state-hack alongside -fspecialise-aggressively creates conflicting optimization pressure. While aggressive specialization attempts to create optimized versions of polymorphic functions to reduce overhead, disabling the state hack may limit the inlining opportunities within those specialized versions. This often results in a scenario where you reduce the amount of memory allocated per call, but increase the time spent executing the call sequence.

Verification Steps

Because the effect is module-specific and varies by GHC version, you must verify the impact using heap profiling. Use the following scoped approach:

1. Compile two versions of the target module: one with default flags and one with -fno-state-hack -fspecialise-aggressively.
2. Execute the binary with RTS options to track allocations:

   ./my-program +RTS -hc -p

3. Analyze the resulting .hp file using hp2ps or eventlog2html to compare total bytes allocated and the allocation rate.

Missing Diagnostic: To refine this recommendation, please provide the -ddump-simpl output for the specific hot-path functions. This allows for verification of whether let-bindings are actually floating or if the state hack was causing unnecessary closure creation in your specific case.