Re: Compile Time Garbage Collection impossible?

Rafael 'Dido' Sevilla <dido@imperium.ph>
25 Sep 2006 01:13:15 -0400

          From comp.compilers

Related articles
Compile Time Garbage Collection impossible? the.real.doctor.zoidberg@gmail.com (2006-09-22)
Re: Compile Time Garbage Collection impossible? pjb@informatimago.com (Pascal Bourguignon) (2006-09-25)
Re: Compile Time Garbage Collection impossible? dido@imperium.ph (Rafael 'Dido' Sevilla) (2006-09-25)
Re: Compile Time Garbage Collection impossible? kym@ukato.freeshell.org (russell kym horsell) (2006-09-25)
Re: Compile Time Garbage Collection impossible? paul.biggar@gmail.com (Paul Biggar) (2006-09-25)
Re: Compile Time Garbage Collection impossible? firefly@diku.dk (Peter \Firefly\Lund) (2006-09-25)
Re: Compile Time Garbage Collection impossible? gneuner2@comcast.net (George Neuner) (2006-09-25)
Re: Compile Time Garbage Collection impossible? liekweg@ipd.info.uni-karlsruhe.de (Florian Liekweg) (2006-09-25)
Re: Compile Time Garbage Collection impossible? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2006-09-25)
[11 later articles]
| List of all articles for this month |

From: Rafael 'Dido' Sevilla <dido@imperium.ph>
Newsgroups: comp.compilers
Date: 25 Sep 2006 01:13:15 -0400
Organization: Compilers Central
References: 06-09-119
Keywords: GC

the.real.doctor.zoidberg@gmail.com wrote:
> When a program is compiled, the compiler has to transverse all its
> code to ensure type safety (for safe languages), so what would be the
> problem in "freeing" objects after their scope, or even better, after
> the last reference in their scope?


When you have dynamically allocated data structures, determining the
scope of such an allocation is generally not so simple to determine
statically. Think of what happens when you pass such an allocated data
structure around among functions, which may put the pointer in different
  variables with different names, and even embed them inside of other
dynamic data structures. This is a difficult job even for a human,
which is why many non-trivial programs written in languages without
automatic garbage collection often have more than a few memory leaks and
related bugs. It seems to me that to determine statically when and
under what conditions a particular function will no longer require such
a dynamic memory block is in the most general case the same as trying to
figure out under what conditions that (partial recursive) function will
halt (please correct me if I am wrong; I would be glad to hear that this
isn't true). That is of course, undecidable. However, I imagine that
it must be possible to come up with some heuristics that will allow it
to make some of these determinations, but they'll likely still require a
supplementary run-time garbage collector to help with the cases they
can't catch.


There was a bit of discussion on this a couple years ago:


http://compilers.iecc.com/comparch/article/03-07-025


You may find that interesting.


Post a followup to this message

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