Why does this simple test program leak 500MB of RAM?

[FeepingCreature]

On Monday, 19 June 2023 at 17:38:17 UTC, Steven Schveighoffer 
wrote:
> On 6/19/23 12:40 PM, FeepingCreature wrote:
>> I'm currently experimenting with setting up a fiber, then 
>> zeroing out its stack completely after the function has run in 
>> it. Results are mixed, but promising. I still end up with 
>> ~100MB live at the end though - which admittedly is a lot 
>> better than 600MB.
>
> Are you looking at GC memory usage or process usage? Because 
> the GC doesn't generally give back memory to the OS even when 
> it could. And fragmentation can stop it from doing so also -- 
> an entire allocated pool has to be unallocated for it to 
> release it to the OS.
>
> I know there has always been mysterious "reasons" for the GC to 
> not collect things that are stack-referenced, but I tend to 
> first try to rule out looking at the wrong information, and/or 
> other simple explanations before getting there.
>

Okay, here's the "full stack cleanup" version: 
https://gist.github.com/FeepingCreature/3baf6bd62dc64441fe73f46e3df9b482

It spawns a fiber, runs the recursion in the fiber, then uses 
madvise and druntime abuse to set the entire fiber stack to zero.

RSS averaged over five runs:

With fiber, without madvise: ~177MB
With fiber, with madvise: ~75MB

But this is extremely weird though. Thinking about it, the 
`madvise` call really shouldn't matter! The fiber has exited, its 
stack shouldn't be a GC root. Even if it is, there should be no 
way that any references to our string[string]s live in any 
possibly-live stack area in there. And yet, explicitly zeroing it 
out repeatably improves GC performance. Conversely, just running 
the recursion in a fiber shouldn't do anything either, either 
that stack area is scanned or it isn't.

Well, empirically, "fiber and cleanup makes rss go down" which is 
the only actual thing of importance, I guess.