mirror of
https://github.com/DeusData/codebase-memory-mcp.git
synced 2026-11-09 09:11:00 +08:00
Martin Vogel
73a15f93ac
Growth investigations were guessing, because the diagnostics snapshot only carried process totals: RSS and committed bytes say memory grew, never where. The map adds allocator-live bytes and a size-class histogram to each snapshot, so a distinctive class identifies the allocation without per-callsite instrumentation. The design constraint is honesty about coverage. Walking the allocator reaches the aggregate heap plus this thread's heap and its abandoned pages, which is not the whole process, and in a build where malloc does not route through the allocator at all it reaches nothing. A per-subsystem tally would report zeros there and read as a clean bill of health. So every snapshot carries three independent totals and an explicit residual -- os_committed, allocator-live, residual = the difference -- and the triple localises growth instead of implying it: live grows leak on a walked heap; buckets say which size residual grows, flat another thread, retention, or non-allocator memory both flat, RSS grows mappings or stacks, not the heap That guard paid for itself immediately. Pointed at the open Windows growth in #581 it reported live=0 with zero blocks and the residual carrying all of it -- not 'the heap is innocent' but 'this walk saw nothing', which is the correct reading for a process demonstrably holding tens of megabytes. Together with the growth surviving a build with the allocator override compiled out, that says the Windows allocations under investigation never reach the allocator, so an allocator-based map cannot localise them and the next instrument has to sit lower down. Covered by a test that allocates a known volume in a known size class and requires the map to attribute it there, so the map can never regress into silently reporting zeros. Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>