Re: [patch] Move loop structures to gc memory

[Alexandre Oliva <aoliva at redhat dot com>]

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?

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

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         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}