It's always tempting to allocate objects on the stack, but there's a good reason why you shouldn't allocate large ones if you care about your application's memory footprint: the stack space you use is used forever, even if you don't need it anymore.

Now you might be wondering, wait a sec, I thought that stack variables are freed when they go out of scope, right? Well, yes and no. Let's talk about this. 🧵 1/8

When you allocate an object on the stack two things are going to happen: the visible one is that the stack pointer will be bumped to make space for your object, the invisible one is that physical memory will be allocated for the object if there's not enough room already.

That is, stacks grow dynamically both in terms of address space (the pointer gets bumped) and in terms of physical memory (pages are allocated to back the address space occupied by the stack). 2/8

The problem is, when deallocating frames only the visible change happens: the stack pointer gets moved back to the previous frame, but the physical memory that has been occupied is not freed. And here lies the problem.

If you've got a ~100 deep stack, chances are it only takes 10-30 KiB of physical memory. But if you had allocated a 256 KiB buffer on the stack, at any point in the past, then your stack takes at least that amount and always will. 3/8

From the operating system's POV that area of memory contains some data you wrote to it and that's the only copy of that data. They're "dirty" in VM speech. So they'll be kept around until the region that holds them gets unmapped (typically when the thread exits and the stack gets deallocated). 4/8

This is not a problem with heap-allocated memory because calling free() or delete is telling the allocator that you don't need that data anymore. And the allocator might decide to unmap it entirely or at least discard the physical pages using a mechanism such as `madvise(..., MADV_DONTNEED)` or `VirtualFree(..., MEM_DECOMMIT)` 5/8