This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] Move loop structures to gc memory

On May 16, 2007, Ian Lance Taylor <> wrote:

> Alexandre Oliva <> writes:
>> On May 16, 2007, "Daniel Berlin" <> wrote:
>> > 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.
>> I don't follow the logic.  Why couldn't pools be in GC memory, again,
>> so as to reap the benefits without complicating the logic?

> Putting something in GC memory unnecessarily is inevitably slower than
> not putting it in GC memory, if only because GC requires overhead to
> track objects.

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.

>> I don't see that allocation patterns that improve locality are
>> necessarily forbidden by GC machinery.  Maybe they're hard to model in
>> our current machinery (I don't know)

> I am talking specifically about gcc's implementation and use of GC.

So is it indeed true that current GGC machinery prevents allocation
patterns that improve locality?  And, if so, is this harder to fix
than maintaining non-GC-controlled roots for all cases in which we'd
like to have better-locality allocation patterns and explicit death
marking than what the default allocation pattern would provide?

I.e., instead of:

  fastobjcollection = alloc (bigenough);
  obj = new_obj_in_collection (fastobjcollection, size);
  ggc_add_root (obj, typedescriptor);
  ggc_remove_root (obj);
  remove_obj_from_collection (obj);
  free (fastobjcollection);

is there any reason we can't have:

  fastobjcollection = ggc_alloc (bigenough);
  ggc_add_root (fastobjcollection, objcollectiondescriptor);
  obj = new_obj_in_collection (fastobjcollection, size);
  remove_obj_from_collection (obj);
  ggc_free (fastobjcollection);
In other words, what does moving the objects out of GCable memory
really buy us?  If the issue is the allocation pattern, we can do
that, and it's not like we can escape completely *some* kind of
object tracking if we need to be able to collect garbage while this
non-GC structure still exists.

Alexandre Oliva
FSF Latin America Board Member
Red Hat Compiler Engineer   aoliva@{,}
Free Software Evangelist  oliva@{,}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]