This is the mail archive of the gcc-patches@gcc.gnu.org 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


Alexandre Oliva <aoliva@redhat.com> writes:

> On May 16, 2007, "Daniel Berlin" <dberlin@dberlin.org> 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.

> This bit is mostly a matter of drawing the line of what it means to be
> GC memory or not (as in, is it GC-allocated or just GC-walkable).

What matters for us is GC-allocated.  We don't collect very often, so
it is fine to have a reasonably small increase in the amount of time
it takes to collect in exchange for a speedup in allocation or
deallocation or access.

> 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), but I got the impression the
> discussion here was about GC in general, not about GGC in particular.
> Maybe I misunderstood.

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

Ian


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