Re: gawk memory leak

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

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