Re: [patch] Move loop structures to gc memory

[Alexandre Oliva <aoliva at redhat dot com>]

On May 17, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

> On 5/16/07, Alexandre Oliva <aoliva@redhat.com> wrote:

>> I'm not sure this follows.  If you have to scan it for pointers to
>> live objects, then you have to track it either as a regular object or
>> as a root.  Tracking it as a root might be slightly cheaper, but it's
>> not without overheads.

> Slightly?

> For basic blocks you are talking about having to mark thousands of
> objects (which includes the root somewhere in it) versus having to
> start at just the root.

It seems to me like you're comparing apples and oranges, so I'll
assume instead that I don't understand what you're getting at.

What I was trying to compare is the overheads of maintaining it as
either a GC root out of GC memory, that requires some explicit or
internal-to-GC data structure to keep it as part of the set of dynamic
GC roots, and some internal-to-memory-mgmt data structure to keep it
as part of the non-GC memory pool, or a regular GC-able object, which
requires something to keep it from being collected (perhaps some
gc_dynamic_roots linked list) and some internal-to-GC data structure
to keep it as part of the GC memory pool.

Both require similar walking functions, so this doesn't make much of a
difference.  I don't see that the overheads in terms of memory are
significantly different for the two cases.  If you get to run a pass
of garbage collection, you're going to walk all live objects,
including all roots, just the same, so I don't see that this pushes
the balance one way or another either.

So I still don't see that the issue is whether the object is a regular
GC object or a GC root.  The issue is whether you can alleviate the
overhead of the memory allocator.  And there are ways to do this, for
which it doesn't matter at all whether the involved objects are GC
roots or non-roots.

What overhead do you see in maintaining the object [pool] as a regular
GC object, that is not present in identical or similar form when it's
a GC root?

>> So is it indeed true that current GGC machinery prevents allocation
>> patterns that improve locality?

> Yes

I don't see what stops you from constructing say an obstack in GC
memory.  What are the obstacles you see?

I now see that using alloca is not a viable option, but you don't want
to allocate big object pools with alloca anyway, which is what I
thought the locality issue was about.

> The fact that you can improve GC locality doesn't mean you should GC
> everything.

"GC everything" may have many different meanings, and I can't tell
which one you mean.

> Because it does not compact memory, doing the second will cause you a
> large amount of gc heap fragmentation

Got it.  A limitation of the internal GGC memory allocator.  Probably
not trivial to fix.

> Not to mention it would mean the GC would still have to track objects
> we don't need it to,

Rather than tracking them as roots, which you seem to regard as
infinitely cheaper but I'm yet to understand why.

> unless you are going to extend gengtype and
> friends, so you can specify which part you want to be a root,

That was the point of the explicit typedescriptor, which presumably
comes with a walk function that specifies how to walk the object.

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}