99% of developers don't get heap memory.

Ask yourself this, is this on the heap

or the stack? At first glance, it might

look trivial, but if you guessed stack,

you're right. Well, mostly. The subtlety

is that returning a pointer to a local

variable is actually undefined behavior.

And if you tried storing data that

outlives the function, you'd need the

heap to avoid a dangling pointer. Did

you catch this critical bug? Let me know

in the comments below. Most developers

overlook the intricate behaviors that

make heap memory fascinating. Things

like fragmentation, coalescing free

blocks, cache locality effects, and

allocator strategies that can

dramatically change performance. You

might think that memory management is

just allocate and free. And you might

not care about these low-level details,

which are themselves very nuanced. But

if you don't know all the jargon that I

just said or just want a deep dive into

heap memory, this video is for you. So,

what is heap memory? Heap memory is a

region of a program's memory used for

dynamic allocation. Meaning data whose

size or lifetime cannot be determined at

compile time. When your program runs and

needs memory on demand for objects that

may outlive the current function or

collections whose size can grow, the

heap is where that memory comes from.

Unlike the stack which works in a very

structured lastin first outway, the heap

is a flexible but more expensive space

managed by an allocator or garbage

collector. So what is the real

distinction between the heap and the

stack? The stack is very tightly

managed. Each function call pushes a

frame with local variables and returns

pop them. It's extremely fast because

the compiler always knows exactly where

values are stored and how long they

live. The heap, by contrast, is managed

at runtime. Allocations require

bookkeeping, metadata, and sometimes

garbage collection, which makes them

much slower. The key difference is

lifetime. Stack variables disappear when

the function ends, but heap objects can

outlive the function that created them.

Here's an example in C. Is this created

on the stack or the heap? X= 10 is

created on the stack. Its lifetime ends

when the function returns. How about

this? Is this created on the stack or

the heap? You can see that there's a

call to maloc. So maloc is designed to

manage memory in the heap to provide

dynamic memory allocation. It allows

programs to request memory during

runtime for data whose size or lifetime

is not known at compile time. And this

memory on the heap persists until it is

explicitly deallocated using free which

gives the programmer control over an

object's lifetime. So what you have to

remember is the size of variables on the

stack must be fixed and known at compile

time with the exception of variable

length arrays in C99. The heap allows

for allocating data of arbitrary or

unknown size at runtime such as an array

whose size is determined by user input.

The stack has a relatively small fixed

size, typically a few megabytes.

Attempting to allocate large amounts of

data on the stack can quickly cause a

stack overflow error. The heap is a much

larger and more flexible memory region

that can grow as needed by requesting

more memory from the operating system.

But how does heap allocation actually

work? When your program asks for heap

memory, for example, with new maloc or

creating an object in Python or Go, the

runtime doesn't just grab random RAM. It

maintains structures like free lists,

size bins, or arenas that track which

blocks of memory are available. When you

allocate something, it finds a block

large enough, marks it as in use, and

returns a pointer. Because the allocator

may need to scan lists, split blocks, or

request more memory from the OS. Heap

allocation is slower and can fragment

over time. Let's quiz you. Stack or heap

this time in C++. Take a look here. Is

this on the stack or the heap? And

similarly here, is this on the stack or

the heap? A is on the stack. The

lifetime is inside fu. New int is on the

heap. you must explicitly delete it.

Note the pointer B itself is on the

stack, but the thing it points to is on

the heap. So who frees heap memory? In C

and C++, you free it manually with free

or delete. If you forget, you create a

memory leak. Modern languages like Go,

Java, and Python use garbage collection

or GC. AGC scans memory, finds reachable

objects, and deletes those that are no

longer referenced. This makes

development easier, but adds overhead.

GC must pause, mark objects, and

sometimes compact or reorganize memory

to reduce fragmentation. But how does

the compiler decide between stack versus

heap? At the compiler level, stack

versus heap placement is determined by a

combination of lifetime or escape

analysis, and compile time knowledge of

type sizes. The compiler always knows

the exact size and layout of statically

sized types, primitives, strrus, and

fixed length arrays. So, it can assign

each one a precise offset in the stack

frame. Stack allocation only works

because sizes and offsets are fully

known at compile time. However, the

compiler must also prove through static

analysis that a value's lifetime is

confined to the function. Meaning, its

address doesn't escape. It isn't

captured by a closure, stored globally,

returned or shared across threads. If

the value might outlive the frame even

though its size is still known, the

compiler cannot safely place it on the

stack. In that case, it instructs the

runtime to allocate the value on the

heap, which is the only region capable

of supporting objects with unbounded or

uncertain lifetimes. Managed languages

like Go and Java use escape analysis to

trigger this promotion. Unmanaged

languages like C or C++ leave the

decision to the programmer via maloc or

new. Just as heat memory dynamically

allocates resources to keep your

application running smooth on the

inside, spacelift dynamically manages

and automates the infra keeping it

running on the outside. Spacelift is an

infrastructure as code orchestration

platform that lets teams provision,

configure, and govern infrastructure

across multi cloud environments using

tools like Terraform, Open Tofu, Anible,

Kubernetes, Cloud Formation, and Palumi.

Spacelift connects to your version

control system, turning infra

repositories into automated workflows

with built-in blueprints and guardrails.

This allows developers to safely self-s

serve infrastructure in a tool agnostic

environment, eliminating bottlenecks and

accelerating delivery. Instead of

manually applying scripts, spacelift

automates runs triggered directly by git

commits and enforces policies written in

open policy agent before changes ever go

live. This gives you a unified view of

infrastructure changes across AWS, GCP,

and Azure, ensuring that the same

deployment standards apply everywhere.

Platform teams can use these features to

build golden paths for developers to

self-service infrastructure safely and

even detect configuration drift

automatically. And unlike solutions that

price based on resources under

management, Spacelift uses concurrency

based pricing, so you're never penalized

for modular infra or engineering best

practices. It's designed for velocity,

control, and flexibility, especially in

enterprise environments that need to

scale infrastructure operations without

surprise costs. A big thank you to

Spacelift for sponsoring this video. If

you want to see how Spacelift can

streamline your infrastructure

automation, check them out down below.

Now, back to the video. Let's talk about

escape analysis. Why some variables move

to the heap. Some languages, notably Go

and Java, use escape analysis to decide

whether a variable can stay on the stack

or must go to the heap. If you return a

reference to a local variable or store

it somewhere that may outlive its frame,

the compiler promotes it to the heap. X

would normally be a stack variable, but

because its address escapes the

function, go allocates X on the heap.

This is exactly the kind of scenario

that produces heap pressure and GC work.

But what is the cost of heap memory?

Heap allocations are slower because they

involve metadata manipulation, possible

synchronization between threads, and

potential garbage collection.

Additionally, the heap can fragment over

time. Many small allocations leave

behind gaps that aren't big enough for

new requests. Garbage collection helps

but doesn't eliminate all fragmentation

patterns. How about multi-threading in

the heap? If you consider multi-threaded

programs, heap allocation can actually

become a bottleneck because threads

compete for memory. Modern allocators

avoid global locks by giving each thread

its own arena or thread local cache.

Goes runtime for example assigns each P

or logical processor its own small

allocator to minimize contention. Let's

look at this example in Python. Are

these allocated on the stack or the

heap? In CPython, all objects live on

the heap, even integers. The names X and

Y live in a local namespace, like a mini

stack, but the actual values live on the

heap. A subtle low-level detail about

heap memory that many developers don't

realize is how the allocator uses

metadata stored right next to your

allocated blocks and how that affects

fragmentation and performance. Most

maloc implementations carve the heap

into chunks, and each chunk carries a

small header that tracks its size,

whether it's free, and sometimes

pointers for free list bookkeeping. When

you free a block, the allocator doesn't

just mark it as available. It also

checks the neighboring chunks in memory

to coales them into a larger free

region, which reduces fragmentation, but

can incur extra pointer chasing and

synchronization if the allocator is

multi-threaded. This means the pattern

in which you allocate and free memory

changes the physical shape of the heap

over time, affecting everything from

cache behavior to how often the

allocator needs to request new pages

from the OS. Even small changes in

allocation order or interle allocations

across threads can lead to surprisingly

different heap layouts and performance

characteristics. So an important

question, why do developers even care

about heap memory? Even in languages

with garbage collection, understanding

heap memory helps you reduce

allocations, reduce pauses, and increase

performance. In Go, for example,

avoiding unnecessary heap allocations

can dramatically reduce garbage

collection pressure in a language like

C++ or Rust. Proper heap usage avoids

fragmentation and also ensures

deterministic lifetimes. Again, if you

want to check out the first ever

multiplayer MCP-based collaboration

platform, check out Glue.ai down below.

And if you want to learn how to build

Docker, Reddus, and compilers from

scratch, I highly recommend checking out

Code Crafters down below.