Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Garbage collection and quality of implementation issues mps@dent.uchicago.edu (1994-05-25) |
| Re: Garbage collection and quality of implementation issues boehm@parc.xerox.com (1994-05-26) |
| Re: Garbage collection and quality of implementation issues jgmorris+@cs.cmu.edu (1994-05-26) |
| Re: Garbage collection and quality of implementation issues mps@dent.uchicago.edu (1994-05-27) |
| Re: Garbage collection and quality of implementation issues mw@ipx2.rz.uni-mannheim.de (1994-05-27) |
| Re: Garbage collection and quality of implementation issues jgmorris+@cs.cmu.edu (1994-05-28) |
| Re: Garbage collection and quality of implementation issues adobe!mhamburg@uunet.UU.NET (1994-05-29) |
| Newsgroups: | comp.compilers |
| From: | jgmorris+@cs.cmu.edu (Greg Morrisett) |
| Keywords: | GC, design |
| Organization: | School of Computer Science, Carnegie Mellon |
| References: | 94-05-105 |
| Date: | Thu, 26 May 1994 15:17:58 GMT |
Michael Spertus <mps@dent.uchicago.edu> wrote:
>This way of looking at it allows a user defined markRefs method. This
>would allow ambiguous data structures, calculated pointers etc. It can
>also import human knowledge of the program and expand the class "things
>the collector is sure will never be needed".
The problem with such an approach is that there is no guarantee that when
I code a new "markRef" method for an object, that it is sound. That is, I
might only mark the first entry of an array as non-garbage, but then I
might go and access the second entry. Consequently, you lose the safety
aspect of garbage collection (i.e. programs can now crash because of
dangling pointers.)
Still, it's a good idea. So the question is, can a compiler verify that
user-defined markRef routines are sound?
-Greg Morrisett
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.