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

[FeepingCreature]

On Monday, 19 June 2023 at 17:38:17 UTC, Steven Schveighoffer 
wrote:
> 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.
>

Okay, I can confirm it's some sort of fragmentation issue.

Printing GC stats:

```
     writefln!"Done. (%s used, %s free)"(GC.stats.usedSize, 
GC.stats.freeSize);
     100.iota.each!((_) {
         GC.collect;
         GC.minimize;
     });
     writefln!"Collected. (%s used, %s free)"(GC.stats.usedSize, 
GC.stats.freeSize);
```

Without alloca purging:

```
Done. (155347088 used, 527275888 free)
Collected. (495808 used, 682127168 free)
```

So all but 500KB GC memory is free, but it uses 796MB residential.

With alloca purging:

```
Done. (35950960 used, 646672016 free)
Collected. (26528 used, 36673632 free)
```

We got rid of another 450KB, but residential dropped to 164MB!

I think miniscule stack leaks must be keeping large GC pools 
alive here.

I kind of wish there was a way to say "1. All allocations in this 
thread should go into a dedicated pool X" and "2. Okay, we're 
done with the work, all remaining references to these allocations 
are a bug; scan for them, crash (with a message) if you find any."