Explain like I'm five · Systems

What is a Process Memory Layout?

Process memory layout and dynamic allocation, told as a story about dividing one car's workspace into fixed zones.

one car gets its own bay in the shopwhere do the blueprint, parts, and temp table go?

The car has a bay, but it's unclear where anything goes.Where do the blueprint, parts, and temp table go?

blueprint and temp parts jumbled together, confusinga fixed rule for dividing the space is needed

Put the blueprint and parts anywhere, and they get jumbled.A fixed rule for dividing the space is needed.

code (blueprint)data/BSS (initial parts)heap (the draw-more warehouse)stack (the temp table)process memory layout = the rule that splits the workspace into fixed zoneseach zone has a fixed job, so nothing gets mixed up

Process memory layout is the rule that splits the workspace into fixed zones.Each zone has a fixed job, so nothing gets mixed up.

Code segmentthe unchanging blueprint
Data/BSS segmentparts prepared from the start
Heap — grows as usedrequests more as needed (dynamic allocation)
Stack — piles up as useda function's share clears itself when the function ends
codedata/BSS (initial parts)heap — grows down this picture as used↓collision = out of memory!stack — grows up this picture as used↑heap and stack grow toward each other — when the gap runs out, memory does too

In this picture (low addresses on top), the heap grows down and the stack grows up.When the gap between heap and stack runs out, memory runs out.

grabbing more from the heap on demand is handynever give it back, and unusable space piles up — a memory leakgive back what you take from the heap, or the workspace runs short

Dynamic allocation is handy, but you must return the space when done.Give back what you take from the heap, or the workspace runs short.

In one breath

A process memory layout fixes zones — code, data, heap, stack — for the workspace, and dynamic memory allocation is borrowing from the heap as needed, then giving it back.

A process's virtual memory is typically laid out, from low addresses up, as the code (text) segment, the data/BSS segment for initialized and uninitialized global variables, the heap which grows via malloc/new during execution, and the stack which grows and shrinks with each function call. The heap grows from low to high addresses while the stack grows from high to low, each toward the other; when the gap between them runs out, an out-of-memory error results. Real operating systems use stack-size limits and guard pages to stop them before they touch. Failing to release dynamically allocated memory with free()/delete accumulates as a memory leak.

When grown-ups say it

Code (Text) Segment
The zone holding the unchanging blueprint. Holds the program's instructions.
Data/BSS Segment
The zone for globally prepared parts. Split by whether the value is initialized.
Heap
The warehouse you draw more from as needed. Grows from low to high addresses.
Stack
The temp table that piles up and clears with each call. Grows from high to low addresses.
Dynamic Memory Allocation
Borrowing as much as needed from the heap. Borrowed with malloc/new, returned with free/delete.
Memory Leak
Space that piles up because it's never returned. Slows down long-running programs.
Stack Overflow
The temp table (stack) spilling past its set limit. Common with excessively deep recursion.
Heap-Stack Collision
Heap and stack growing toward each other until they collide. Once the space between them runs out, no memory is left to use.
Next story
Mixing the Best Dial Settings Together →
Want another term as a picture book? Request →