Re: Garbage collection and quality of implementation issues

Michael Spertus <mps@dent.uchicago.edu> wrote:
>No. All power involves risk. I believe that user defined markRefs
>functions give enough power to justify their risk. In practice users are
>very carefull writing such things.


Wait a minute. If programmers are pretty good about writing such things,
why don't we stick with malloc/free? I mean, can't I just define
free(obj) to mean overwrite the GC method for obj so that it marks nothing
when invoked?


I agree that GC methods are a good idea -- I just think that punting on
the safety issue _entirely_ is going pretty far. I'm asking if there
isn't some way to verify that, say, 90% of the user-defined markRef
methods aren't sound.


>The compiler can warn if unions, calculated pointers etc are used and a
>user markRefs is not given. Most garbage collected languages do not allow
>these structures.


Untagged unions -- true. Tagged unions -- false. Calculated pointers --
depends on the implementation. (See Eliot Moss's Modula-3 implementation
and the GC toolkit out of UMass.)


There are two other problems with user-defined GC methods. One is closely
related to finalization methods: GC/finalization methods are invoked
_asynchronously_, in no order that the programmer can control. The
asynchrony can be a real problem. What do you do if the GC method is
invoked in the middle of another method? In particular, suppose that
interrupted method uses derived pointers in temporaries? The other
problem is time overhead during collection. Invoking a method for each
object to be marked/scanned can be _very_ expensive.


-Greg Morrisett
--

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