This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Move loop structures to gc memory
On 5/16/07, Alexandre Oliva <aoliva@redhat.com> wrote:
On May 15, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> I agree that putting things into GC space just because they point to
> GC things (even though they themselves have obvious lifetimes) is a
> lameness of our GC.
I'm not sure I understand what you mean. Not doing so implies either
pinning the pointed-at objects by hand (yuck) or adding the "things"
as GC roots, which is really not that different from GC-allocating
them as roots in the first place.
Except that you lose all the benefits of it *not* being in GC.
As a concrete example:
Our basic blocks were pool allocated using alloc_pool's.
Because they started pointing to GC'd structures directly (in order to
simplify things), we switched them to be gc alloced.
We lost about 1-2% compile time from doing this (see the archives),
because alloc pools are contiguous in memory, and our gc was just
handing out random free memory that happened to be around the same
size.
Things that have a very well defined lifetime (which are basic blocks
do, for example), should not have to be in GC memory simply because
they point to GC objects.
You can argue that "well, it doesn't really hurt most of the time",
"we could improve the GC to get better locality" etc, but it doesn't
change that basic premise. No one in this thread has yet given a good
reason we should have to GC things that we don't want to GC, just to
get things they point to GC'd without really ugly hacks/workarounds.
The only reason i've seen is "well, it's hard".
Speed wise, profiles of the GC have never shown the actual root list
walking to be slow, only the actual mark lookups and sets. Adding
dynamic roots would make the root list walking slightly slower, but if
we have *less* things in GC overall, we will do less mark setting,
which is where most of GC time goes.
So it should be a win overall.