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

[Hans Boehm]

On Jan 22,  5:24pm, John R Levine wrote:
> Subject: RE: [gclist] Re: PPC & GC, or GC and threads
> > Garbage collection is fundamentally about moving work from the
> > programmer to the computer, and the code generator is going to have
> > share some of that work.
>
> Well, sure, but since GC is a relatively infrequent activity compared to
> evaluating expressions, and on architectures without direct addressing,
> code that never hides a pointer can be difficult or bulky to generate.
> You can imagine other ways to deal with this problem, e.g., sort-of-soft
> preemption points.
>

It's important to remember that the effects here are all fairly minor.  The
observed performance degradation in my 1996 PLDI paper
(http://reality.sgi.com/boehm/papers/pldi96.ps.gz) for SPARC, where there was a
reasonably complete implementation was about 2% in time and 5% in space.  The
implementation here used a preprocessor + postprocessor.  Without the
postprocessor the slowdown on SPARC and Intel Pentium was around 9%.  The vast
majority of this was due to the use of an unmodified gcc and a gross hack based
on the asm facility.

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.

You can combine all of this with a safe-point notion and reduce the cost
further.  But I suspect that by the time you have an integrated implementation
you're talking about reducing the slowdown from 1% to 0.5%.

Hans


-- 
Hans-Juergen Boehm
boehm@mti.sgi.com