You already know branch predictors guess conditional jumps. But ret is an indirect jump — its target is whatever address sits on top of the stack. The CPU can't wait for that load to resolve; the pipeline would stall for dozens of cycles. So it keeps a dedicated predictor just for returns: the Return Stack Buffer (RSB), also called the Return Address Stack.

The RSB is a small hardware stack — typically 16 entries on Intel, 16–32 on AMD, 8 on older ARM cores. Every time the CPU decodes a call, it pushes the predicted return address (the instruction after the call) onto the RSB. Every ret pops from it and speculatively jumps there. If the actual return address (loaded from memory later) matches, you pay nothing. If it doesn't, the pipeline flushes — 15–25 cycles wasted.

Where this breaks:

• RSB underflow. Return deeper than 16 calls and the RSB is empty. The CPU falls back to the generic indirect branch predictor (BTB), which is far less accurate for returns. Deep recursion or long call chains tank here.
• RSB overflow. Call deeper than 16 frames, then return. The oldest entries are gone, so the first 16 returns predict correctly, but everything beyond mispredicts.
• Call/return mismatch. Code that does call without matching ret (or vice versa) corrupts the RSB. Setjmp/longjmp, coroutines that swap stacks, and exception unwinding all poison it. Every subsequent return mispredicts until the RSB realigns.

Real example: Go's goroutine scheduler used to do stack switches via assembly that confused the RSB. Switching between two goroutines would mispredict every return until the RSB drained. The fix was an explicit call/ret dance to keep the RSB balanced — measurable throughput gains on call-heavy workloads.

Spectre-RSB / Retbleed connection: Attackers learned to poison RSB entries to make returns speculatively jump to attacker-chosen gadgets. Mitigations like RSB stuffing — filling all 16 entries with a known safe address on context switch — exist for this reason. That stuffing also explains why the first ~16 returns after a context switch are predicted, even if your real call chain is shallower.

Rule of thumb: If your hot path has a call chain deeper than ~15 frames and returns frequently, you're paying for RSB underflow. Inline aggressively, flatten recursion into iteration, or tail-call where possible. A perf stat -e br_misp_retired.return will show you the misprediction count directly.