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;
}
[download]

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

• Memory is not released back to operating system by bloonix (2012)
• Re^2: Timing of garbage collection by me (2013)

• FFI::Platypus: Replace malloc with GC_MALLOC? by karlgoethebier (2022)
• FFI::Platypus

• Destructor (computer programming) (wikipedia)
• Garbage collection (computer science) (wikipedia)
• Tracing garbage collection (wikipedia)
• Manual memory management (wikipedia)
• Automatic Reference Counting (wikipedia)
• Boehm garbage collector (wikipedia)
• C dynamic memory allocation (wikipedia)

• Re: Perl Memory problem ... (Memory Tools References)

Updated 2022: Added paragraph about manual memory management.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.