RE: Projects

[Tom Tromey <tromey at cygnus dot com>]

Hans> Different GC options probably can't hurt for embedded
Hans> applications.  Otherwise, it seems to me they can hurt if they
Hans> effectively introduce different ABIs, e.g. for inlined write
Hans> barriers.

I agree this is a problem.  We could probably solve it with multilibs.

Hans> 4) Collector performance on many platforms, especially X86, is
Hans> very sensitive to compiler performance.  The inner loop in our
Hans> collector, as compiled with gcc, seems to be mainly spill code.
Hans> My intuition is that I could do substantially better by hand,
Hans> though I may be wrong.

If we can track this down to missed optimization opportunities, or
something like that, we might be able to get the compiler people to
fix it.  There seems to be a lot of interesting work going on in gcc
these days.

Hans> A smaller root set helps.

It would probably be possible for us to explicitly register the roots,
so that we wouldn't have to scan the entire data segment.  How much
would that help?  For instance, we could register a class's static
fields at class initialization time.

Hans> It would be nice to have the option of a fully precise copying
Hans> collector to get reasonable space bounds for embedded
Hans> applications.  Other than that, I'd proceeed cautiously.

There definitely aren't concrete plans to do anything other than what
we're doing.  I want to keep our options open, if it makes sense.  If
we can get write barrier code into gcc, I don't think that will hurt.
In the worst case we won't use it.

Tom