Re: Garbage collection and quality of implementation issues

[re user written markRef methods]
>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


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.


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.


There are several language design theories on how to approach risky user
decisions.
Always trust the user, Assembler
Generally trust the user, C
Never trust the user, Eiffel


We are experimenting with
Never trust the user unless she says trust me then trust her.


A lot of programs are much better off with the null collector (never
delete anything). This is also a risky decision but we allow it.


One way that the user says trust me is to write a user defined markRefs
function. We generate code for blocks by having them respond to a
buildCode message. This message has a default implementation and few users
will ever want anything else but we allow that method to be overridden.
This is the ultimate trust. If you allow the user to call external
functions you have given that ultimate trust because those functions may
have been written in assembler.
--

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