9.2 Activation Records and Stack Frames
An activation record is the runtime package of one function invocation. Stack frame is the concrete in-memory layout that stores that package.
Even in languages with aggressive register allocation, frames matter for:
- saved return context
- spilled temporaries
- debugging and unwinding
- ABI-required storage
A frame is not "just local variables." It is a control-flow and state-recovery structure.
Typical Frame Ingredients
Depending on target ABI and optimization level, a frame may include:
- return address
- saved frame/base pointer
- callee-saved registers
- argument shadow space or outgoing-call area
- locals and spills
Some optimized leaf functions omit frame pointers entirely. Others keep stable frame chains to improve debugging and exception unwinding.
Returning from a function is only possible because the frame preserves enough information to restore caller context.
Recursion and Depth Costs
Recursion makes frame mechanics visible: each call level pushes one more frame. That gives elegant semantics but costs stack space per level.
Given stack size and average frame size , a rough depth bound is:
Real systems need margin for runtime frames and library calls, so safe production limits are lower than this theoretical bound.
Tail-call optimization changes this picture for certain call shapes by reusing current frame slots instead of growing the stack.
Worked Insight
When a profiler shows deep recursion pressure, the compiler engineer has three levers:
- reduce per-frame footprint
- enable valid tail-call elimination
- rewrite algorithmic recursion shape
All three decisions depend on activation-record understanding, not only source-level algorithm analysis.