[gclist] Re: PPC & GC, or GC and threads

[Dave Lloyd]

Hans Boehm wrote:
> There is every reason to expect that with an implementation that's integrated
> into the compiler even the 2% number could be significantly lower.  After all,
> empirically nearly all optimized C code is GC-safe, even on PPC.  The only
> trick is to make the analysis strong enough so that it doesn't slow down code
> unnecessarily.  Even when the code needs to be changed, the only cost is that
> you may have to use an additional register in order to avoid in-place updates.
>  This often doesn't cost anything, but may occasionally result in extra
> register spill code.

Indeed. Our Algol 68 and Fortran 90 compilers were designed with an 
integrated precise garbage collector (of the mark and sweep variety). 
The compiler tracks all references statically and ensures that 
*somewhere* there is a root pointer for all objects being manipulated. 
This root pointer may well be in an outer procedure frame - our calling
convention includes the rule that references passed to procedures must 
be recorded in the ref map. In almost all cases, the worst this means is
that there is a marginally redundant copy on the stack, but scope and a 
few compiler optimisations usually mean that this is not within a
critical loop, but at the top of the frame. Since our GC is
precise we don't care if the code-generator generates mangled pointers 
to improper parts of objects as long as the objects are rooted
somewhere (and this can be several indirections away by leaning on the 
type system) . The main impact on the code-generator is when new objects
are created, we have to take a little care in the 'gap' between 
allocation and initialisation - this is particularly important for 
compound objects which need several separate allocations, sometimes 
there has to be a temporary place holder (with a simplified type) in the
refmap for the duration.

I can't compare code with and without GC since it is fundamental to our 
compiler, but I have never seen an example where the GC imposes an 
observable penalty on real code - we usually beat g77 for numeric 
intensive loops - and the F90 vector forms that can use the heap more 
heavily often run faster not slower (but thats because not all scalar
loops are easy to vectorise).  Its harder to compare Algol 68 and C 
code, but for the simple examples I have tried (some geometry stuff such 
as building a Voronoi diagram) we beat C (malloc/free seems relatively
expensive).  What the GC contribution to all this is I don't really 
know, but at the end of the day if the complete solution wins, it can't
matter too much! Oh for the time to do some proper experiments...

Regards,
----------------------------------------------------------------------
Dave Lloyd                            mailto:Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd    http://www.occl-cam.demon.co.uk/
Cambridge, England                    http://www.chaos.org.uk/~dave/