What does the activation record pushed for one call to a telemetry ingest routine actually hold?

A routine's text is written once, but a *call* of it needs storage of its own: somewhere to remember what it was handed, what it has computed so far, and where to go when it finishes. That storage is the **activation record** — commonly called the **frame** — and it is created when the call begins and released when the call returns. Keep the setting concrete: a device driver calls a telemetry ingest routine once per sensor reading, handing it a record to fill. Every one of those calls gets its own frame. ## What is in the frame | Part | What it is for | |---|---| | Return address | The point in the caller to resume at when this call finishes | | Saved caller state | The caller's frame base, and registers this routine must hand back unchanged | | Parameter slots | The values (or locations) the call copied in | | Locals | The variables declared inside the routine, for this call only | | Temporaries | Storage for part-finished expressions and for arguments being assembled for a nested call | | Result space | Where the value being returned is placed, when it does not simply travel in a register | Two things are deliberately **not** in it. The routine's instructions are not: code is shared by every call, and copying it per call would be absurd. And anything whose lifetime must outlast the call is not: a frame is released at the return, so storage that has to survive lives elsewhere. ## Why one frame per call Each call needs its **own** parameters, locals and return address, because each call is at a different point in its work and was handed different arguments. That is the entire reason a routine can call itself, or be entered again from a nested call, without the two interfering: the name `count` inside the routine resolves, at run time, to the slot in *this* call's frame. - A routine that recurses to depth 40 has 40 live frames, each with a full set of locals. - A routine entered again from something it called has two live frames, and the inner one's writes to its locals are invisible to the outer one. - The **return address** differs between those frames even though the routine is the same, because each was called from a different place. ## The stack discipline Frames come and go in strict last-in-first-out order: the most recently entered call is always the next to finish. That fact is what makes the frame store a **stack**, and it buys two things: 1. **Allocation is a bump.** Entering a call moves one marker by the frame's size; returning moves it back. There is no search for free space and no bookkeeping of which blocks are in use. 2. **Release is free and exact.** At the return, the whole frame stops being live in one step — no scan, no per-variable cleanup accounting. The price of that bargain is that the storage is reclaimed *whether or not* anyone still refers to it. A frame's lifetime is decided by the call structure, not by who still holds a route into it. ## Frame size A frame's size is usually fixed for a given routine and known before the program runs: the compiler counts the parameters, locals and the worst-case temporaries and reserves that much. It is not universal across routines — a routine with many wide locals has a much larger frame than one with two scalars — and it need not be fixed even for one routine, where a language allows a local whose size depends on an argument. This matters far beyond bookkeeping: how deep a routine can recurse is decided by its frame size against the bounded region the stack occupies, not by a count of calls. ## What this buys you when reasoning Most questions about calls become mechanical once you can picture the frame: - "Why doesn't the recursive call clobber my loop counter?" Because the counter is a local, and each call has its own. - "How does the routine know where to go back to?" Because the return address was written into the frame at the call. - "Why is my routine's state gone on the next call?" Because locals live in a frame that was released. - "Why did this crash only on the big batch?" Because depth multiplied by frame size outgrew the region reserved for frames. Note that a frame holds only what one call needs *while it is running*. Storage whose lifetime must exceed the call — a record a caller keeps, a buffer handed onward — cannot live in it, which is the single most consequential fact about the whole arrangement.