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, "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?

I do understand the benefits of locality, I just don't understand how
GC allegedly gets in the way of the techniques we use to improve

And then, one way or another, if you don't want GC to collect objects
pointed to by objects in these pools, there are two ways to approach
the issue: either the referring objects are in GC memory and
referenced by roots (or roots themselves), or they're in non-GC memory
and the GC machinery must be able to walk objects (or at least roots,
which would require all such referring objects to be registered as
roots) in non-GC memory.

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).

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.

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]