[gclist] Compiler specialized GC's

[Dave Lloyd]

> > Charles Fiterman wrote:
> > > > Our GC generates a marking routine for each type in the system rather than
> > > > interpreting a type description during GC. Makes for quite a fast
> > > > traversal.
> > >
> > > Do you allow user defined mark functions. We have found those very useful.
> > > The classic example is the stack where the mark function should only look in
> > > the live section. I have a good compiler hash table example where the table's
> > ...
> >
> > We don't have user mark functions as the type system is sufficient to find all
> > available pointers (we *only* trace the live stack(s) - follow up the frames,
> > find where we are in the code and then check the REFmap for pointers off the
> > stack).
>
> 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).  

I'm not discounting the original idea. I can see particular application 
to the problem of interacting with alien (other language) code which
might hold pointers not held in our own space. A user mark function that
can untangle hand coded data-structures (e.g., C unions) would be 
invaluable at times.
----------------------------------------------------------------------
Dave Lloyd                            Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd    Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK