State variable lifecycle when subroutine invoked via goto &sub

Direct answer

No. A Perl state variable is not eligible for reclamation merely because normal calls to its subroutine stop. While the subroutine's compiled code reference (CV) remains defined and reachable, its lexical pad and the state scalar stay allocated. goto &sub performs a tail call on the same CV; it does not create a new pad or free the existing one. In a long-running loop that repeatedly invokes the same subroutine through goto &sub, treat the state variable as effectively permanent.

Confirmed facts

• state is available from Perl 5.10 onward.
• Initialization runs once per lexical scope/CV, and the value persists across entries.
• goto &sub replaces the caller's frame but reuses the callee's CV; it does not allocate a new subroutine or pad.
• The CV's pad is freed only when the CV becomes unreachable or the interpreter thread exits.
• There is no separately collectable "state stash." The symbol table holds the name-to-CV glob entry; the state scalar lives in the CV pad.

Likely explanation

Perl reclaims storage by reference counting. Because a named subroutine remains reachable through its stash entry, or because a coderef is held elsewhere, the CV and its pad are not freed. The state scalar therefore survives for the life of the CV, not for the life of the most recent caller. If goto &sub targets a newly created anonymous subroutine each iteration, each CV has its own state variable, and prior storage can be reclaimed only when that earlier CV becomes unreachable.

Assumptions and uncertainty

This assumes Perl 5.10 or later and ordinary reference counting. A state scalar involved in a reference cycle may persist even after its CV appears dropped, until the cycle is broken. Behavior under threads or interpreter cloning is not addressed here.

Steps for this case

1. Confirm the interpreter is Perl 5.10 or later: perl -e 'print $]'
2. Determine whether the same CV is reused. Print Scalar::Util::refaddr(\&mysub) before and after several iterations; a stable address means the same pad and persistent state.
3. If the target is one fixed CV, do not use state for per-iteration data. Pass an explicit accumulator or argument, or use a package variable or hash you control.
4. To release storage safely, make the CV unreachable outside the subroutine, then redefine it. Do not undef &mysub or remove it from its stash while executing inside it via goto &sub.

Missing diagnostic detail

Is goto &sub aimed at one fixed named subroutine or stable coderef, or at a newly created anonymous subroutine each iteration? This changes whether prior state storage is collectable.

Verification

Read the state value across iterations. If the value persists and refaddr is unchanged, retention is caused by the same CV, not by the absence of normal calls. To test release safely, drop all references to the subroutine only when not executing it, define a new subroutine with the same name, and confirm that state initializes fresh.