[gclist] Compiler specialized GC's

[Charles Fiterman]

> >
> > You miss the point. What if that is a user stack not the system stack. Yacc
> > for example keeps a large user stack.
> 
> I'm not missing the point.  What guarantees that pointers down the stack 
> will not be accessed again (from the compiler's point of view)?  How do 
> you avoid a window of vulnerability when the stack grows again?  These 
> are not issues that programmers are used to dealing with as they only 
> arise when a GC can come along and take a peek at any time.  There are 
> more robust solutions such as assigning NIL to rewound slots in a user 
> stack to assist the GC (or use linked lists and release the stack 
> directly).  
> 
>From the compilers point of view nothing guarantees any of these things.
Users writing their own mark functions can create bugs. The stack class
must guarantee that new frames start zeroed or whatever. 

Assigning NIL to rewound slots in a user stack is extra work for the
user in doing the assignment and extra work for the collector in
examining them.

User Mark routines can be the best encapsulation of some ideas. My best
example of this is a hash table. Under some circumstances such as the 
first pass of a compiler a table has an obligation to keep things alive
simply because they were put on the table. Under others such as the second
pass of the compiler the hash table has no obligation to keep things
alive. If the collector deletes them their destructors should manage
their removal from the table. Any other implementation of this is complex
badly encapsulated and likely to be buggy, circular references within
the table for example.