|Lots of things are happening with ACM TOPLAS email@example.com (1997-03-31)|
|gawk memory leak [was Re: Lots of things are happening with ACM TOPLAS firstname.lastname@example.org (1997-04-02)|
|Re: gawk memory leak email@example.com (1997-04-03)|
|Re: gawk memory leak firstname.lastname@example.org (stuart(yeates)) (1997-04-06)|
|Re: gawk memory leak email@example.com (1997-04-06)|
|Re: gawk memory leak firstname.lastname@example.org (Max Hailperin) (1997-04-06)|
|Re: gawk memory leak email@example.com (1997-04-07)|
|Re: gawk memory leak firstname.lastname@example.org (1997-04-07)|
|Re: gawk memory leak email@example.com (1997-04-07)|
|Re: gawk memory leak firstname.lastname@example.org (1997-04-07)|
|Re: gawk memory leak email@example.com (1997-04-08)|
|Re: gawk memory leak firstname.lastname@example.org (1997-04-11)|
|Re: gawk memory leak email@example.com (1997-04-11)|
|[2 later articles]|
|From:||firstname.lastname@example.org (Henry Baker)|
|Date:||7 Apr 1997 15:00:28 -0400|
|References:||97-03-165 97-04-020 97-04-022 97-04-037|
email@example.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
Return to the
Search the comp.compilers archives again.