Re: gawk memory leak

Arnold D. Robbins (arnold@mathcs.emory.edu) wrote:
>: Ob. comp.compilers note. This memory leak stuff has thoroughly
>: convinced me of the beauty of purify, as much as I otherwise really
>: dislike software patents. It has also convinced me that automatic
>: garbage collection a la Java is a Good Thing. :-)


"...automatic garbage collection a la Java"? As if Java invented gc?
Hmm.


By the way, I'd be interested in hearing exactly what is patented,
re: purify.


Mike Albaugh <albaugh@agames.com> wrote:
> 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.


I think you're right. To me, "garbage" means "any memory that's being
consumed by objects that will never be referenced again by the
program". And of course it's impossible for a garbage collector to
detect all such. For one thing, which objects will be used in the
future depends on input data, which can't be predicted. Even without
any input data in the future, you'd have to solve the halting problem
to properly detect all "garbage" in this sense. Therefore, garbage
collection is necessarily conservative -- that is, it fails to reclaim
some memory that could be reclaimed.


But so what if gc doesn't completely solve the problem? It partly (or
even mostly) solves the problem, and is therefore good.


You'll find some gc zealots who claim that gc "prevents memory leaks"
or "prevents dangling pointers". It doesn't prevent these problems,
but it sure can help.


It's like type checking. There are those folks who claim that type
checking (or program proofs, or whatever silver bullet) will prevent
all bugs. And there are those who react to such nonsense by rejecting
the idea of type checking (or proofs, or whatever). More reasonable
to say that type checking helps prevent a certain class of bugs, and
that's good, but not perfect.


(There are those gc zealots who define "memory leak" conveniently to
match what garbage-collectors can do. And there are those proof
zealots who define "correct" conveniently to match what automatic
provers can prove.)


>Sure, memory leaks are more _likely_ with rookies (or, mortals :-)


Yeah, that's the point -- we (programmers) are all mortals, no matter
how smart we are. Just because technique X doesn't completely solve
the problem does not mean that X is worthless.


>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 :-)


GC is a Good Thing, I think. It prevents *most* memory leaks, and
*most* dangling pointers, which is good, but not perfect. Don't be
confused by claims that it solves all the worlds problems (and then
fails to do so, and therefore is worthless).


If you're interested, join the gc mailing list. There, you can find
all kinds of zealots, and reasonable folks, who will all try to
convince you of the error of your ways. ;-)


- Bob
--

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