Great questions—memory allocation behavior can be surprisingly nuanced, so let’s break this down clearly based on how modern OSes and allocators work.

1. Is heap allocation more efficient in large memory block paging scenarios? #

First, let’s get a key constraint out of the way: stacks have a fixed (configurable but limited) size and grow in a single, contiguous direction. Most Linux distros set a default stack size of 8MB; Windows is similar. Try to allocate a large block (say, 10MB) on the stack, and you’ll immediately hit a stack overflow crash—heap allocation is the only viable option here.

When it comes to paging efficiency, stack paging is handled passively by the OS: every time your stack pointer crosses into an unmapped virtual page, a page fault triggers, and the OS maps a single physical page to that virtual address. For large blocks, this means multiple sequential page faults, each carrying kernel-mode transition overhead.

Heap allocators (like glibc’s ptmalloc or Windows’ HeapAlloc) are smarter for large blocks. They’ll bypass the regular heap’s small-object free list and directly call mmap (Linux) or VirtualAlloc (Windows) to request a contiguous chunk of virtual memory. Many OSes let these calls map physical pages in batches (or use Transparent Huge Pages, THP, to map 2MB pages instead of 4k), cutting down on page fault overhead. Plus, large heap allocations live in their own isolated regions, avoiding fragmentation issues that plague small-object heap usage.

2. Is heap allocation more efficient for memory blocks of ~64k and above? #

64k is right around the threshold where stack allocation starts to become risky or inefficient, even if your stack has enough remaining space. Here’s why heap wins:

• Flexibility: Stack memory is tied to the current function frame—it’s automatically freed only when the function returns. If you need to release the memory mid-function, or pass it to another function that outlives the caller, stack memory won’t work. Heap memory can be freed explicitly and shared across the program.
• Reusability: When you free a 64k heap block, most allocators will keep that mapped memory around for future allocations of similar size. This skips the overhead of system calls and paging entirely. Stack memory, once freed, is returned to the OS—you can’t reuse it within the same stack frame.
• Stack overflow risk: If your function is recursive, or other parts of the program have already used a chunk of the stack, a 64k allocation could push you over the stack limit. Heap allocation has no hard size limit (other than available system memory).

3. Stack uses on-demand paging—do heap allocators handle this more efficiently (e.g., batch mapping virtual to physical pages)? #

Absolutely. Stack paging is passive and per-page: the OS only maps a physical page when a page fault occurs, one page at a time. For a 64k block (16x4k pages), that’s 16 separate page faults, each requiring a kernel transition.

Heap allocators handle large blocks with active, batch paging: when you request a 64k block, the allocator will ask the OS for a contiguous virtual address range, and many OSes will map physical pages in batches (or use THP to map a single 2MB huge page if possible). This means no page faults when you first access the memory—all physical pages are already mapped.

Additionally, heap allocators can cache these large blocks. If you free a 64k block, the allocator might not immediately unmap it with munmap/VirtualFree. Instead, it’ll keep the block in a pool for future allocations, so the next time you need 64k, you get a pre-mapped chunk with zero paging or system call overhead. Stacks can’t do this—once stack memory is freed, it’s gone back to the OS.

内容的提问来源于stack exchange，提问作者user835943