|Static Garbage Collection firstname.lastname@example.org (Matthias-Christian Ott) (2009-05-25)|
|Re: Static Garbage Collection email@example.com (Tony Finch) (2009-05-26)|
|Re: Static Garbage Collection firstname.lastname@example.org (George Neuner) (2009-05-25)|
|Re: Static Garbage Collection email@example.com (2009-05-26)|
|Re: Static Garbage Collection firstname.lastname@example.org (Dmitry A. Kazakov) (2009-05-26)|
|Re: Static Garbage Collection email@example.com (Florian Stock) (2009-05-26)|
|Re: Static Garbage Collection firstname.lastname@example.org (Matthias-Christian Ott) (2009-05-26)|
|[6 later articles]|
|From:||Matthias-Christian Ott <email@example.com>|
|Date:||Mon, 25 May 2009 21:28:01 +0200|
|Posted-Date:||25 May 2009 19:51:47 EDT|
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.
[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
Return to the
Search the comp.compilers archives again.