Re: gawk memory leak

albaugh@agames.com (Mike Albaugh) writes:


> I keep running into this sentiment. I'm definitely not
> "pro memory leaks", but I don't understand exactly what definition
> of the term makes it not apply to objects that are still "live"
> long after they are _usefully_ live, in garbage-collected systems.
> Sure, memory leaks are more _likely_ with rookies (or, mortals :-)
> doing malloc/free at a dizzying pace, but garbage collection _per_se_
> does not solve the base problem of not having a handle (pun intended)
> on the useful life of your objects. Unless there is something major
> I'm missing, I'm afraid I'll continue to view garbage collection
> in the "Not _much_ Spam in it" category :-)


I'll answer from experience -- I've got a fair bit of experience
dealing with both kinds of memory leaks, the kind that occurs in a
garbage collected system when you retain a reference to something you
aren't actually going to use, and the kind that occurs in a
manual-deallocation system when you fail to deallocate.


In the garbage collected system, you need to reason locally: each
module needs to say that "if *I* don't need this widget anymore, then
*I* shouldn't hang onto a reference to it anymore." If each module
does that, then when no module needs the widget anymore, none will
have a reference, and so it will become garbage collectable.


In the manual-deallocation system, you need to reason globally: each
module needs to say that "if I don't need this widget anymore, and I
am the *last* module that did need it, then I should deallocate it."
In other words, you need to reason about not only your own module's
lack of future need for the widget, but also about all the other
modules, in order to determine whether you are the last.


In both cases, it is necessary to do some sort of reasoning. The
dream many people have that you can avoid reasoning about these issues
at all is just a dream. With GC, you get away with it more often,
which serves to lull people into complacency, and then one day they
get burnt big time, typically by refering to lots of big objects from
"inactive" portions of a data structure (like elements of an array
beyond the number that some counter tells you are "in use"). If you
can overcome the complacency, it is relatively easy to get the
reasoning right, however, because of its local nature. With manual
deallocation you get burnt all the time, so you never get complacent,
but despite the constant reminder that you need to reason, you still
find it very difficult to do so correctly, because of the globalness.


The best programmers of manual-deallocation systems typically go to
great lengths to avoid having to do fully-general global reasoning
about the question "am I the last". For example, they may copy
structures that there is no logical reason to copy, so long as there
is no necessity of sharing. For structures that need to be shared,
they may designate an explicit "owner" who all the other users "check
in" and "check out" with, effectively manually implementing reference
counting. Etc. For simple situations it isn't too bad, but for hairy
stuff this effort can easily overwhelm the effort actually devoted to
the program's intended purpose.


So, no garbage collection doesn't solve the memory leak problem by
itself, in the sense of without thought, but it isn't just a matter of
making leaks less common (and premature deallocations/reallocations
impossible). Instead, it is a matter of making the reasoning much
easier that it takes to make the leaks go away entirely, as opposed to
just becoming less common.


  -Max Hailperin
    Associate Professor of Computer Science
    Gustavus Adolphus College
    800 W. College Ave.
    St. Peter, MN 56082
    USA
    http://www.gac.edu/~max/
--

Return to the comp.compilers page.
Search the comp.compilers archives again.