3 ms·
> significantly less memory overhead On an OS with overcommit, you might also only pay for what you use (at a page granularity), but this may be defeated if th
by aidenn0 1y ago
> significantly less memory overhead
On an OS with overcommit, you might also only pay for what you use (at a page granularity), but this may be defeated if the stack gets cleared (or initialized to a canary value) by the runtime.
- vlovich123 1y agoNot just cleared. Each stack would get dirtied to the largest depth and that memory never gets reclaimed even if you only hit that deep of stack once. And the OS’s only way to reclaim that is if the allocator frees that page (in practice rarely particularly for glibc) or it gets swapped to disk (expensive since unused pages end up getting swapped too)
- aidenn0 1y ago> Each stack would get dirtied to the largest depth and that memory never gets reclaimed even if you only hit that deep of stack once Right, but the issue under discussion was that "right sizing" stacks is hard. You always need to have a stack sized to at least the largest depth. Pages that get swapped out to disk and never accessed again aren't that expensive. Disk is cheap.