Re: gawk memory leak

marssaxman@sprynet.com.antispam (Mars Saxman)
11 Apr 1997 00:05:46 -0400

          From comp.compilers

Related articles
[6 earlier articles]
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)
Re: gawk memory leak chase@naturalbridge.com (David Chase) (1997-04-11)
Re: gawk memory leak pfoxSPAMOFF@lehman.com (Paul David Fox) (1997-04-13)
| List of all articles for this month |

From: marssaxman@sprynet.com.antispam (Mars Saxman)
Newsgroups: comp.compilers
Date: 11 Apr 1997 00:05:46 -0400
Organization: Red Planet Software
References: 97-03-165 97-04-020 97-04-022 97-04-037 97-04-046
Keywords: GC, storage

hbaker@netcom.com (Henry Baker) wrote:
[snip of discussion]
> 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_).


I'm in the process of implementing the application framework portion
of a new development system. The language itself doesn't have a
garbage collector, but the framework will include basic GC facilities.


Our solution to the "list of every object" problem is to make the
runtime module's list of objects accessible (indirectly) to the
programmer. Since the GC knows about this list, it will delete
anything (and remove it from the list) if that list contains the only
reference to the object. Obviously, there is nothing to stop the
programmer from making a second, parallel list-of-all-objects, but the
probability is that they won't waste time redeveloping a feature the
framework already contains.


-Mars
--


Post a followup to this message

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