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] |
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]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.