GC statistics (was Re: big project ported)

[Tom Tromey]

>>>>> "Kresten" == Kresten Krab Thorup <krab@daimi.au.dk> writes:

Kresten> The alternative is to invent a new and very clever garbage
Kresten> collector. Good luck.

There are actually plenty of options we could implement without having
to invent something new.

Jon Olson has done work on adding write barriers to gcc.  This is the
technology needed for incremental and generational GC.  (Yes, the
Boehm GC has incrementality.  However, a paper I've read indicates
that write barriers based on page protection schemes have poor
performance.)  Integrating his work might be hard, since it needs to
go through gcc.  Jon, have you tried submitting these patches?

Incremental and/or generational collectors will have better
characteristics for some applications, but not for all of them.

We could also write a mostly-copying collector that is tuned to work
with libgcj and nothing else.  This might be a win in other
situations.

I don't know if any of these will really happen.  Bigger projects
require a committed volunteer, or funding.  (I'm personally very
interested in GC, but I also don't have the free time to commit to it.
Bummer.)

The ultimate goal here is to have pluggable GC support.  This doesn't
have to be run-time pluggable; something like the current thread
system would be fine (here our embedded bias shows: run-time pluggable
GC would probably be better on the desktop).  We want pluggability so
that the right GC can be chosen on a per-application basis.

Tom