Pinpointing memory leaks in production Haskell deployments
summary
GHC RTS patch adds a lightweight profiling mode that tags every closure with a GCI per-closure tagging ID, dumps HP snapshots to a file, and reports exact block and heap accounting (GC ID, mega/4K block counts, 4K block utilization and live-bytes percentage). It identifies pinned 4K fragmentation caused by small pinned allocations, surfaces long-lived closures (example: allocated at GC 50 and still live at GC 99), and runs with minimal allocation overhead (only a couple of extra stores).
AI-written summary · about
chapters (11)
- 0:00Memory leak debugging in Haskell
- 1:08Memory usage increase in production
- 2:15Haskell memory leaks and fragmentation
- 7:59Limitations of Haskell profiling tools
- 11:09Lightweight profiling patch
- 13:19Analyzing memory snapshots
- 27:14Live memory and fragmentation data
- 28:21Heap tree inspection for leaks
- 35:12Filtering heap dumps
- 37:18Future GHC improvements
- 39:05Q&A
related talks
01h 24mWhat we have learned about memory profiling in the last 5 years
01h 30mGHC's Runtime System
30mLightweight profiling with ghc-stack-profiler
15mUsing MMTk Garbage Collection in GHC (Lightning Talk)
01h 02mOptimising for fast builds with GHC
58mGHC Status Report
01h 26mReflections on Haskell@Meta
26mghc-specter: a GHC plugin that inspects the GHC state on live