[gclist] Re: PPC & GC, or GC and threads
Tue, 27 Jan 98 12:41:38 GMT
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...
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/