Ok. I have a sort-of repro: * [https://gist.github.com/pb-cdunn/9ac52d96d1791cbb2412e76865748a13](https://gist.github.com/pb-cdunn/9ac52d96d1791cbb2412e76865748a13)
When I run that in [https://glot.io/new/nim](https://glot.io/new/nim), things seem fine. And they are fine on my Mac. (I'll double-check soon.) But on my Linux VM, it does this: n=1 ... n=1073741824 tot=4296118272 occ=3221426176, free=1074692096 b4 tot=4296118272 occ=3221430272, free=1074688000 now n=1 ... n=1073741824 tot=5370155008 occ=3758309376, free=1611845632 b4 tot=5370155008 occ=3221438464, free=2148716544 now n=1 ... n=1073741824 tot=6712696832 occ=3758309376, free=2954387456 b4 tot=6712696832 occ=3221438464, free=3491258368 now n=1 ... n=1073741824 tot=6712700928 occ=3758313472, free=2954387456 b4 tot=6712700928 occ=3221442560, free=3491258368 now n=1 ... It remains stable from there on, so maybe the manager prevents any given freelist from growing forever. But even this much is unacceptable. I have 48 cpus on a 96GB machine, so I have only 2 GB available to each thread. Plus, when I run single-threaded (without spawn), my own program's free-space grows without bound, until I kill it. When I use `ulimit -m/-v`, it runs out of memory, which is also sub-optimal behavior. If I can be confident that the freelists are contiguous, then maybe I could rely on the Linux swapper to swap them out of memory, but my co-workers would still not approve. This is a serious problem.
