Static Garbage Collection

Matthias-Christian Ott <ott@mirix.org>
Mon, 25 May 2009 21:28:01 +0200

          From comp.compilers

Related articles
Static Garbage Collection ott@mirix.org (Matthias-Christian Ott) (2009-05-25)
Re: Static Garbage Collection dot@dotat.at (Tony Finch) (2009-05-26)
Re: Static Garbage Collection gneuner2@comcast.net (George Neuner) (2009-05-25)
Re: Static Garbage Collection torbenm@pc-003.diku.dk (2009-05-26)
Re: Static Garbage Collection mailbox@dmitry-kazakov.de (Dmitry A. Kazakov) (2009-05-26)
Re: Static Garbage Collection stock@esa.informatik.tu-darmstadt.de (Florian Stock) (2009-05-26)
Re: Static Garbage Collection ott@mirix.org (Matthias-Christian Ott) (2009-05-26)
[6 later articles]
| List of all articles for this month |

From: Matthias-Christian Ott <ott@mirix.org>
Newsgroups: comp.compilers
Date: Mon, 25 May 2009 21:28:01 +0200
Organization: Compilers Central
Keywords: GC, question
Posted-Date: 25 May 2009 19:51:47 EDT

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


Regards,
Matthias-Christian
[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]



Post a followup to this message

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