Re: Copying collection and our ggc_collect practices

[Daniel Berlin <dberlin at dberlin dot org>]

On Wed, 17 Sep 2003, Per Bothner wrote:

> Zack Weinberg wrote:
>
> > Ok, so that's pretty easy to turn into a file-scope static as ggc
> > needs.  I seriously suggest you do a sweep, find all of these, and fix
> > them.
>
> Turning local variables into file-scope variables would however
> be a step backwards in terms of modularizing or library-izing gcc.
> You might say: don't worry about that, it will never happen,
> but similarly major changes (including library-izing cpp) have
> happened.
>
> And of course using a file-scope global instead of a local variable
> does hurt optimization.
>
> The ideal solution would be to have compiler support for copying
> or non-conservative gc,
That would be nice, but i *Certainly* don't have time to implement it.
I just do this gc work for fun, it's kinda a hobby that i know has the
potential to speed up the compiler and reduce memory usage.


> just as we have compiler support for exception
> handling.  For example java uses a conservative non-copying collector
> because it cannot be sure what the compiler does with locals.  There
> are other applications that would like precise gc.

We actually have a precise marking gc right now.
The problem is that marking is slower than molasses.

Incrementalizing it is an option, but that requires type codes (i've got
patches to do this and use it), or queueing of marks prior to real
marking, because you need to be able to restart marking from certain
points.  We  dirty a lot of pages in between collections (I tracked it
with mprotect), so it might not be a win in all cases.

We also run into pretty bad fragmentation problems that cause our memory
usage to be way too high.  It's a function of two things:

1. We allocate a lot of garbage in between passes.
2. We end up allocating things with wildly divergent lifetimes at the same
time for some reason.

Thus, we end up with pages that have 1 or 2 live objects in them, blocking
us from freeing the entire page.

The zone collector is bucketless, so it can at least reuse the entire rest
of the page, but it's still not the best option for locality.

In order to try to combine the best of both worlds, i was going to do what
a lot of Java VM's are doing now, which is have a nursery/first generation
where objects are first allocated, and do copying collection on that, and
then promote things into mark and sweep zones.


I've actually implemented these things pretty robustly (IE it passes
bootstrap with GCAC checking) in a relatively short time, but i don't
allocate trees and rtl with the copying collector (they get allocated
directly into mark/sweep zones), due to the numerous places we expect the
pointers to stay the same over GC.


--Dan