Perl 5.32 state keyword: recursion persistence ambiguity

Does a `state` variable keep its value across recursive calls?

In Perl 5.32 a state declaration creates a *static lexical* – a single SV that is shared by every activation of the enclosing subroutine. Consequently, a recursive subroutine should see the same state variable and its current value on each deeper call. A typical test that increments the variable at each depth prints a monotonically increasing sequence, confirming persistence.

Why do some tests show a reset?

• Re‑compilation of the subroutine: If the subroutine is redefined (e.g., via eval, sub { ... } inside a loop, or a dynamic no strict block that redefines the sub), Perl compiles a fresh copy. Each compilation creates a new static state variable, so the value appears to reset at that depth.
• Dynamic code loading: Loading a module that defines the same subroutine name will also recompile it, leading to a new static variable.

Under normal, single compilation scenarios the variable does not reset; the observed behaviour is a side‑effect of redefinition, not a bug in the state implementation.

Performance impact

Accessing a state variable involves a static lookup, which is only a few CPU cycles more than a plain my lexical. Benchmarks of a factorial routine that caches intermediate results in a state versus a my variable show less than 1 % difference in total run time for typical recursion depths (up to a few thousand). The overhead is negligible compared to the cost of the expensive computation being cached.

Best‑practice guidance

• Use state when you intentionally want a value to survive across all calls of a subroutine, e.g., memoizing results in a recursive algorithm.
• Do not define a state inside code that may be recompiled at runtime (dynamic eval, reloading modules, or sub redefinitions). If the sub can be redefined, prefer a plain my lexical and pass the cache explicitly.
• If a per‑call cache is needed, keep it as a my variable or an argument to the subroutine.
• Use Devel::Peek::Dump during debugging to confirm that the state SV is static and shared:

  use Devel::Peek;
  sub foo {
      state $cnt = 0;
      $cnt++;
      Dump($cnt);
  }
  foo();
  foo();
  

• Always test on the target Perl version. state was introduced in 5.10, but its semantics were refined in 5.32; older releases will not compile.

In short, a state variable behaves as documented: it persists across recursive calls in a single compiled subroutine. The apparent reset you observed is almost always due to the sub being recompiled. Performance penalties are negligible, and the key to avoiding subtle bugs is to keep state declarations in stable, non‑recompiled code blocks.