Beefy Boxes and Bandwidth Generously Provided by pair Networks
XP is just a number
 
PerlMonks  

Re^2: Do subroutine variables get destroyed? (Deterministic Destructor References)

by eyepopslikeamosquito (Bishop)
on May 08, 2016 at 16:37 UTC ( #1162494=note: print w/replies, xml ) Need Help??


in reply to Re: Do subroutine variables get destroyed?
in thread Do subroutine variables get destroyed?

To elaborate further on GrandFather's point that perl uses a reference-counted garbage collector, note that with Perl you get "deterministic destructors" for free; that is, in perl, you are guaranteed that an object is destroyed (and destructor called) immediately its reference count goes to zero. BTW, deterministic destructors are a feature of the C++ RAII idiom yet are problematic when using a tracing garbage collector, such as that used by Java ... which is why Java has a "finally" clause (see also Dispose pattern). See also Finalizer (wikipedia).

You can use deterministic destructors to good effect in Perl with lexical file handles, which are automatically closed when the file handle goes out of scope; for example in:

sub fred { # Lexical $fh is known from point of declaration (next line) to en +d of scope open(my $fh, "<", "f.tmp") or die "open error f.tmp: $!"; # ... process file here # We assume no references to $fh are created in and returned from +this sub # (if you did that reference count of $fh would not be zero on sub + exit) # ... die might be called ... (that's ok, can be caught via block +eval) # ... there can be multiple return statements ... return; }
note that $fh is automatically closed immediately the function exits because the $fh variable goes out of scope at end of function ... and when $fh goes out of scope, its reference count goes to zero and its destructor is automatically and immediately called to close the file handle. No need for an explicit close. (Update: this automatic close at end of scope does not check for errors though, so an explicit close with error checking is advisable for file handles used for writing; see also autodie).

A drawback to reference counting, that tracing GCs solve, is the dreaded circular reference problem. For an example of how to deal with circular references in Perl, see Eliminate circular reference memory leak using weaken (perlmaven). See also Automatic Reference Counting and Weak reference and Circular reference (wikipedia).

As to when malloc'ed memory is actually released back to the OS, see the answers to this question.

What I dislike more than both reference-counting and tracing garbage collectors is Manual memory management, typical in C programs ... which forces you to rely on static and dynamic code analysis tools, such as Coverity, Valgrind, AddressSanitizer and many more, to keep the code clean. See also EXTERNAL TOOLS FOR DEBUGGING PERL section at perlhack.

References Added Later

Updated 2022: Added paragraph about manual memory management.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1162494]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2023-02-05 20:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I prefer not to run the latest version of Perl because:







    Results (32 votes). Check out past polls.

    Notices?