Re: gawk memory leak

hbaker@netcom.com (Henry Baker)
7 Apr 1997 15:00:28 -0400

          From comp.compilers

Related articles
Lots of things are happening with ACM TOPLAS toplas@cs.umd.edu (1997-03-31)
gawk memory leak [was Re: Lots of things are happening with ACM TOPLAS arnold@mathcs.emory.edu (1997-04-02)
Re: gawk memory leak albaugh@agames.com (1997-04-03)
Re: gawk memory leak stuart@cosc.canterbury.ac.nz (stuart(yeates)) (1997-04-06)
Re: gawk memory leak bobduff@world.std.com (1997-04-06)
Re: gawk memory leak max@gac.edu (Max Hailperin) (1997-04-06)
Re: gawk memory leak hbaker@netcom.com (1997-04-07)
Re: gawk memory leak cyber_surfer@wildcard.demon.co.uk (1997-04-07)
Re: gawk memory leak bobduff@world.std.com (1997-04-07)
Re: gawk memory leak clark@quarry.zk3.dec.com (1997-04-07)
Re: gawk memory leak arnold@mathcs.emory.edu (1997-04-08)
Re: gawk memory leak bobduff@world.std.com (1997-04-11)
Re: gawk memory leak marssaxman@sprynet.com.antispam (1997-04-11)
[2 later articles]
| List of all articles for this month |

From: hbaker@netcom.com (Henry Baker)
Newsgroups: comp.compilers
Date: 7 Apr 1997 15:00:28 -0400
Organization: nil
References: 97-03-165 97-04-020 97-04-022 97-04-037
Keywords: storage, GC

  bobduff@world.std.com (Robert A Duff) wrote:


> 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.


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


A correctly implemented GC in a conscientiously applied program of
type hygiene solves _all_ dangling pointers, so your statement is
incorrect. There are systems called 'conservative' (what a misnomer!)
GC's that can under certain conditions cause dangling pointers, but
that is because they are not 'precise' -- i.e., correctly synchronized
to the language. This abuse of the language ('conservative') has
caused me much anguish, and I hope much embarrassment for Xerox PARC
(the language abuse, that is).


GC's prevent most of the usual sorts of 'memory leaks', but still fall
prey to the program that forms a list of every object ever allocated!
You are correct that determining the uselessness of such lists is
equivalent to the halting problem. Some 'memory leaks' of this type
are caused by an incorrect understanding of the problem, and may be
the result of weird interactions among different modules. Good tools
to track memory usage are always welcome, and can often turn up other
kinds of 'dead bears' (silent bugs that haven't woken up and bitten
anyone _yet_).
--


Post a followup to this message

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