in reply to Memory leaks and reference counting within Perl.

I think there may be confusion about what constitutes a "memory leak". A memory leak occurs if memory is not freed at the point the last reference to that memory goes away. There are 3 ways to get a memory leak in a perl program: construct a circular reference (as described by other comments above); find and tickle a bug in perl's reference counting; or find and tickle a bug in some other external non-perl code (such as an XS library).

It is possible to write a program that consumes more memory than it needs to because it keeps unnecessary references to data, thus making the memory unavailable for reclamation. But that is simply an inefficiency in the program (often fixable by more carefully restricting the scope of variables), not a memory leak.

Hugo

  • Comment on Re: Memory leaks and reference counting within Perl.

Replies are listed 'Best First'.
Re^2: Memory leaks and reference counting within Perl.
by Joost (Canon) on Jan 06, 2005 at 18:13 UTC
    There are 3 ways to get a memory leak in a perl program: construct a circular reference (as described by other comments above); find and tickle a bug in perl's reference counting; or find and tickle a bug in some other external non-perl code (such as an XS library).
    And those potential bugs in the perl interpreter and XS libraries are IMO the biggest drawback of a reference counting scheme. Circular references in perl are usually easily avoided (you can now even use weakrefs with the standard distribution if you need to) - but when you're writing extensions or modifying the interpreter you need to get the reference count correct in all C/C++ code using perl's data types. This is extremely brittle, when you consider passing subroutine arguments, changes in scope, stuffing data in lexicals, mortal SV*s etc etc. At least, I usually mess it up hard :-)

    As far as I understand it, a "real" garbage collector can replace most of this mess with a centralized (but complicated) garbage collection algorithm. at the cost of (usually) not guaranteeing a specific destroy time for objects (perl objects are at the moment guaranteed to be DESTROYED at the exact moment they go out of scope). AFAIK perl 6 is going to implement a scheme like this - which means you won't be able to count on "timely destruction" in perl 6 (at least, last time I looked).

    "What should it profit a man, if he should win a flame war, yet lose his cool?"
[reply]

In Section Seekers of Perl Wisdom