Re: Static Garbage Collection

George Neuner <>
Mon, 25 May 2009 22:09:59 -0400

          From comp.compilers

Related articles
Static Garbage Collection (Matthias-Christian Ott) (2009-05-25)
Re: Static Garbage Collection (Tony Finch) (2009-05-26)
Re: Static Garbage Collection (George Neuner) (2009-05-25)
Re: Static Garbage Collection (2009-05-26)
Re: Static Garbage Collection (Dmitry A. Kazakov) (2009-05-26)
Re: Static Garbage Collection (Florian Stock) (2009-05-26)
Re: Static Garbage Collection (Matthias-Christian Ott) (2009-05-26)
Re: Static Garbage Collection (Vincent Belliard) (2009-05-26)
Re: Static Garbage Collection (Hans-Peter Diettrich) (2009-05-29)
[4 later articles]
| List of all articles for this month |

From: George Neuner <>
Newsgroups: comp.compilers
Date: Mon, 25 May 2009 22:09:59 -0400
Organization: A noiseless patient Spider
References: 09-05-120
Keywords: GC
Posted-Date: 28 May 2009 17:36:46 EDT

On Mon, 25 May 2009 21:28:01 +0200, Matthias-Christian Ott
<> wrote:

>today I stumbled upon a very intresting problem on garbage collection:
>Suppose we have a goto-free, pointer-less, static strongly typed
>programming language without any binary libraries (so all source code
>is available at compile time).
>Then we could construct the control flow graph for the entire programme.
>Couldn't we than statically (of course depending on conditions during
>runtime) determine the locations for the appropriate malloc() and free()
>calls, depending on if a referenced object is no longer used?
>The result would be same as if you manually managed you memory, so you
>would have no runtime overhead garbage collection, just for the tests of
>the user input, because we can predict everything that does not depend
>on user input at compile time.

Google "region based memory management".

>[This feels like it's equivalent to the halting problem which is known to
>be insoluble in the general case, albeit often soluble in specific
>instances. -John]

It's not quite that bad. The best you can do with some allocations is
approximate their lifetimes ... so any solution would necessarily be
equivalent to a conservative GC. The major difference is that
deallocations can throw away a whole heap at a time so the amortized
cost of operation is less than GC.


Post a followup to this message

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