runtime: background scavenger is overzealous with small heaps #32012
Description
Today the background scavenger will treat newly-mapped heap memory as unscavenged, which means that if you have an application with a small heap (such as 24 MiB) on Linux, then it will scavenge 64 - 24 = 40 MiB, which is a fair bit of work to be doing.
However, those 40 MiB were never touched in the first place, so they haven't been faulted in and don't count against your RSS anyway. The scavenging work is totally unnecessary.
Instead, we should probably treat newly-mapped memory as scavenged so that this issue is avoided. It also more accurately represents reality, and by tracking this in HeapReleased, the runtime will have a better measure of the application's heap RSS.
The one caveat here is that on Windows we currently map new heap memory as MEM_COMMIT|MEM_RESERVE which means that Windows counts all of that against your RSS. But there's a clear solution here too: if we just map memory as MEM_RESERVE and then only map it as MEM_COMMIT upon allocation, we can get this right.
There isn't currently a noticeable performance impact from this so I don't think this is terribly high priority, but it could affect the "warm-up" time of applications on systems without huge pages and with larger arena sizes (e.g. Linux w/o THP, AIX, etc.). Aside from that, it would also be nice to just make the accounting a little bit better here for small heaps.
CC @aclements