Just to expand on the above:

In garbage-collected languages it is generally a bad idea to worry about exactly when a specific piece of data is garbage collected. It will happen at the runtime's convenience, no sooner, and no later. Doing immediate collection is generally more work (at runtime) than it is ever going to be worth.

So, expect that timing to change on different boxes, runs, and if you recompile. The only thing you are in good shape to be sure of it that it will happen after the variable has gone out of scope.

Expanding a bit further.

That comment only applies to mark-and-sweep type garbage collection. As a general rule, Perl's reference-counted garbage collection is deterministic and mostly handles as you would expect. (Present case excepted, of course.)

Personally, I regret the loss of a defined, consistent object lifetime caused by using mark-and-sweep. Having the lifetime of a object determine the timing of events is quite useful. It's one of the reasons I prefer Perl and C++ to Java.

G. Wade

case in point:

package H;
sub DESTROY { print "DESTROY\n"; }

sub new { my $class = shift; bless {}, $class; }

{
    if(my $h = H->new()) {
        print "IN\n";
        undef $h;
    }
    print "\$h out of scope\n";
}
print "why now?\n";
[download]

produces:

IN
DESTROY
$h out of scope
why now?
[download]

As does:

package H;
sub DESTROY { print "DESTROY\n"; }

sub new { my $class = shift; bless {}, $class; }

{
    {
        if(my $h = H->new()) {
            print "IN\n";
        }
    }
    print "\$h out of scope\n";
}
print "why now?\n";
[download]