Summer of Code project discussion

[Daniel Jacobowitz]

On Tue, May 02, 2006 at 09:07:19PM +0200, Laurynas Biveinis wrote:
> Having that in mind, also because I actually like doing
> infrastructural projects, cleaning up, speeding up things instead of
> implementing new features, I think I have found a suitable area for my
> project: garbage collection. I was looking for a compiler speed-up
> project yet avoid sinking into tree/RTL internals, as I doubt I would
> learn them effectively in time.

Hi Laurynas,

I wrote a lot of the current zone collector.  Before that, Daniel
Berlin did a lot of work on it.  I really don't think I have time to
mentor an SoC project (Daniel, do you, maybe?), but I'd be glad to talk
to you about possible plans.

> - Investigate possibility of Boehm GC usage for compiler proper.
> Project page mentions inconclusive previous results here. I tried to
> google them in mailing list archives to no avail. Could somebody
> provide pointers to the previous investigation?

I don't know of any offhand (which doesn't mean there isn't any).

> - Assuming that Boehm GC turns out to be unusable for the compiler,
> finish the zone collector. Again, searching mailing list about what's
> unfinished was not very fruitful.

What's there works.  I don't remember if it is sufficiently portable to
e.g. systems without mmap to use as the default; and it needs some
performance tuning still, probably, although I did a lot.

> - Assuming zone collector is done well before deadline, tune the
> collector by creating special zones for data with special lifetime.

This turned out not to make a huge amount of difference; the problem is
that the lifetimes of things are unclear in GCC and often long.  I
wrote a collector which could separate out data only referenced by a
single function into its own zones; less than 30% of all data in a GCC
run is specific to a function, because things like types and constants
are not.  I think it was even less.  I don't have the statistics handy.

The copying part of the collector worked well.  The partitioning was
less useful.

My plan was to eventually enable generational GC; i.e. to be able to
collect more frequently and assert that data for other functions had
not changed since the last collection, since we optimize one function
at a time.  You could even mprotect the other zones read-only under
--enable-checking to verify that we didn't clobber other functions.
The problem was that the global zone was so large that collection time
was still high.

On March 13th 2005 I posted the copying collector to gcc-patches; you
can find it in the archives.  That was good for a performance boost by
itself of a few percent, but used a lot of RAM; something cleverer
might be doable that would use less RAM; I don't really know.  I don't
think I ever posted the automatic partitioning code; that computer is
off right now, but I can dig out the code if you want to see it.

-- 
Daniel Jacobowitz
CodeSourcery