Also known as: memory management
Memory management is how a running program obtains memory to hold its data and reclaims it once that data is no longer needed — a defining characteristic of a language that shapes its safety, speed, and fitness for real-time work.1
Stack vs heap
A program’s memory splits into two regions. The stack holds local variables and function call frames; a frame is pushed on a call and popped on return, so its memory is freed automatically and allocation is nearly free — but everything on it must have a size known at compile time and lives only as long as its function. The heap is a flexible pool for data whose size or lifetime is not known up front; it must be allocated and eventually released, and all the hard memory problems live on the heap because something must decide when each piece is no longer needed.1
Three strategies
Languages differ chiefly in how they reclaim heap memory.
Manual management — C and C++
— gives you malloc/free and total control, but risks leaks, use-after-free, double
frees, and buffer overflows.1 Garbage collection —
Go, Java,
Python — automatically frees unreachable memory,
eliminating whole bug classes at the cost of occasional, non-deterministic pauses.
Ownership — Rust — uses a compile-time borrow checker
to free memory at known scope exits, achieving safety with no garbage collector and
deterministic timing.
Why it matters
The key axis for real-time work is determinism. Manual and ownership models reclaim memory at predictable moments, so a software-defined radio pipeline never stalls mid-buffer; garbage collection can pause at an unpredictable moment and drop samples. This is why tight DSP gravitates toward C or Rust, while a GC’d language like Go is fine for the control and orchestration layers around it.
Sources
-
Memory management — Wikipedia, on stack versus heap, manual allocation, and automatic reclamation strategies. ↩ ↩2 ↩3