DEV Community: Suvijak Vinyunavan

The Heap Memory

Suvijak Vinyunavan — Mon, 30 Jun 2025 21:35:56 +0000

The Heap

In the previous article, we discussed stack memory. In this article, we’ll complete the answer to the question: “Why is the stack faster than the heap?”, and also touch on why the heap is typically larger, but slower than the stack.

How to Use the Heap 🔨

A natural way to introduce heap memory is by showing a working example of how it’s used in programs.

Access 🗄️

Heap memory is a region that a program accesses by explicitly requesting a block of memory from the operating system. Unlike stack memory, data stored on the heap remains valid after a function exits.

For instance, when a function contains stack-allocated variables, those variables are automatically deallocated when the function returns. Attempting to access them afterward leads to undefined behavior, since the memory may have been overwritten.

int* stacktest() {
    int arr[100] = {0};
    int* ptr = &arr[0]; // Pointer to stack memory
    printf("Allocated memory at: %p\n", (void*)ptr);
    return ptr; // Returning pointer to stack memory (not recommended)
}

int* calloctest() {
    int* arr = (int*)calloc(100, sizeof(int));
    printf("Allocated memory at: %p\n", (void*)arr);
    return arr;
}

int main() {
    const int* sptr = stacktest();
    const int* hptr = calloctest();

    printf("Allocated stack memory at: %p\n", (void*)sptr);
    printf("Allocated heap memory at: %p\n", (void*)hptr);

    printf("Stack memory value: %d\n", *sptr); // Access stack memory
    printf("Heap memory value: %d\n", *hptr);  // Access heap memory

    free((void*)hptr); // Free heap memory
}

Output:

Allocated memory at: 00000006C899F590
Allocated memory at: 0000011A01D49540
Allocated stack memory at: 00000006C899F590
Allocated heap memory at: 0000011A01D49540
Stack memory value: -929434080
Heap memory value: 0

stacktest creates a zero-initialized array on the stack and returns a pointer to the array on the stack. calloctest allocates a zero-initialized memory span on the heap and returns a pointer to the memory location.

In this case, the stack array we attempted to access contains corrupted values, not the zero we initialized it with. This is an example of stack corruption, where the memory was reused or overwritten after the function exited. This is due to the stack being a contiguous memory block which the program and functions use to perform operations they need. This is not how the stack is supposed to be used. Stack memory should not be accessed when it has left the scope, even though accessing it is still possible.

In contrast, the heap-allocated memory remains intact and returns the expected zero. This is because calloc initializes the allocated memory to zero, and the memory is allocated in an arbitrary location in the memory, making it much less susceptible to being randomly corrupted by other function calls or random memory access.

Size ↔️
The heap is also allowed to be much larger than the stack. For example:

void StackOverflow() {
    // Allocate 800MB on the stack
    double arr[100000000] = { 0 };

    for (double i : arr)
        printf("%d", i);
}

Output:

(process 56272) exited with code -1073741571 (0xc00000fd). // Stack overflow

Allocating 800MB on the stack causes a stack overflow because it exceeds the default stack size (on Windows it's about 1MB).

In contrast, the heap handles large allocations without crashing:

void HeapNoOverflow() {
    // Allocate 800MB on the heap
    double* arr = (double*)calloc(100000000, sizeof(double));

    if (arr == nullptr) {
        printf("Memory allocation failed!");
        return;
    }

    for (int i = 0; i < 10; i++)
        printf("%", arr[i]);

    printf("Allocated memory at: %p", (void*)arr);

    free(arr); // Free memory
}

Output:

Allocated memory at: 0x1e2c1fd0070
(process 53076) exited with code 0 (0x0).

Heap memory is not subject to a strict size cap like the stack, and thus 800MB can be asked from the heap without much problem. It can also be allocated from arbitrary locations in virtual memory.

How Does the Heap Work?

Prerequisites

To understand heap allocation, it helps to know a few key terms:

🍿Kernel: The core part of an operating system, responsible for managing CPU time, memory, and hardware interaction at the lowest level.
📄Page: A fixed-size memory block (typically 4096 bytes) used by the kernel to manage memory. Memory is allocated in pages rather than individual bytes for efficiency.

Allocation
Heap memory is allocated differently from the stack. The stack typically has a fixed size (e.g., 1MB on Windows), pre-allocated when a program starts. In contrast, the heap must be requested at runtime from the OS.

When you call malloc, the C standard library first tries to find space in memory pages already assigned to the process. If no space is available, it performs a system call to the kernel to request additional memory pages.

The kernel may:

Return a pointer to the allocated memory,
Or return MAP_FAILED to indicate allocation failure.

This address is passed back through the system layers from the kernel to the C library to malloc, and finally to the caller.

This is much more complicated than the stack, where allocation is often just a pointer subtractions and pointer arithmetics.

Summary

Why Is the Heap Slower?

The complexity of heap allocation — requiring coordination between:

The C runtime,
The operating system kernel,
Bookkeeping data structures for memory blocks and pages,

…makes it significantly slower than stack allocation.

Additionally, heap memory must be manually managed with malloc and free, introducing more opportunities for bugs like memory leaks, double frees, and dangling pointers.

This means heap allocation is powerful but comes with cost:

Slower due to system calls and metadata tracking,
Harder to manage due to manual deallocation,
Larger and more flexible than stack memory.

Use heap memory only when necessary, such as when:

The data must outlive a function,
The size is too large for the stack,
Or the lifetime is dynamic and unpredictable.

The Stack: Why It’s Fast and How It Works

Suvijak Vinyunavan — Sat, 24 May 2025 17:18:55 +0000

While many programmers are familiar with the concept of the stack, a common question arises: Why is it faster than the heap, even though both reside in the same physical memory? This article aims to answer those questions to the very low level to satisfy the thirst for understanding of some curious individuals out there.

Let’s not waste any more time and dive into the depth of the stack memory architecture.

📚What is the stack?

The stack memory, allocated for every local variable and function calls, follows a strict, well-known, Last in first out (LIFO)data structure: the latest item has to be removed first in order to access the previous stack. Each segment of the stack, which corresponds to each allocations and scope, is called a “stack frame”.

(Figure 1: stack data structure illustration)

🧪An Example in C and Assembly.

To better understand the stack memory, we need an example to follow by and explain.

Supposed you call a function - add():

int add(int j, int k) {
    int a = 10;
    int b = j + k;
    return b;
}

Which compiles to the following assembly(I promise it’s not as scary, I will explain them through) looks like:
add:

        push    {r11, lr}
        mov     r11, sp
        sub     sp, sp, #16
        str     r0, [r11, #-4]
        str     r1, [sp, #8]
        mov     r0, #10
        str     r0, [sp, #4]
        ldr     r0, [r11, #-4]
        ldr     r1, [sp, #8]
        add     r0, r0, r1
        str     r0, [sp]
        ldr     r0, [sp]
        mov     sp, r11
        pop     {r11, lr}
        bx      lr

To understand the stack and how it’s allocated, we need to introduce some terminology and conventions first:

📚 The stack frame is a region of memory allocated on the call stack for each function call in a program, which in the lower level, is the area between the frame pointer fp and the top stack pointer sp.
☝️Frame pointer, together with the stack pointer, are the anchor points which the entire stack will operate relative to. They will never be changed throughout the entire process, and only change when the stack frame change ie. new stack allocation.
⏬The stack grows conventionally downwards, which means that when we allocate a stack on top of the existing one, the memory address of the new stack is lower than the previous one.
📝r11 refers to a register in this case used as the frame pointer, and sp refers to the stack pointer

🧱Breaking down the assembly

Every time a stack has to be allocated the computer does the following

        push    {r11, lr}
        mov     r11, sp
        sub     sp, sp, #16

push {r11, lr} instructs the processor to put anything inside r11 which is currently the previous stack’s frame pointer, and lr (link register used for returning from a function) onto the stack and decrements sp by 4 per each item, 8 in total.
mov r11, sp sets the frame pointer to the stack pointer
Finally sub sp, sp, #16 decrements sp by 16 to make space for the 16 bytes we need for the function’s local variables and parameters.

(Figure 2: stack allocation step by step illustration)

This concludes the stack allocation. The memory region between the stack pointer (sp) and the frame pointer (r11) constitutes the current function’s stack frame.

🔠Variables

On line 7, we can see the assembly associated with initializing the variable a to 10:

        str     r0, [sp, #4]

This instruction stores the value from register r0, which currently holds the value 10 from the previous mov instruction, into the memory location at an offset of 4 bytes from the stack pointer.

This convoluted way of refering to a place in memory is required for the flexibility of the function to be called whenever and wherever in the code, since all the local variables would be just offsets in the frame itself. Different compilers have different approaches to how to use the stack, but essentially they all use location relative to the stack position for local variables.

You might wonder where do these memories come from? The truth is, all processes on the system get preallocated a stack space it can use without requesting for more memory, by default about 1 - 8MB depends on the operating system. This means that programs already have the stack memory they need already allocated to them, but this also means that the stack is limited to only the space allocated for them at the beginning of the program. This limited preallocation is the reason why using too much of the stack memory (ie. from deep recursive function or an array too big) often leads to a stack overflow error.

The mechanics used to allocate the memory being essentially moving pointers up and down requiring only a few instructions is a major factor contributing to the exceptionally quick allocation of the stack memory, compared to heap memory which requires complicated book keepings of the entire heap area and operating system calls for more memory, making the stack memory far better suited for local small allocation such as variables, which does not need to persist through to other scope of the program.

✅To Summarize

Stack allocation is fast due to simple pointer arithmetic.
The CPU provides specific instructions optimized for stack operations.
Stack memory is preallocated, eliminating the need for dynamic memory requests during execution.
Stack size is determined at program start, and memory is automatically reclaimed when a function exits.