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


On May 17, 2007, Ian Lance Taylor <iant@google.com> wrote:

> 1) It is cheaper to call pool_alloc than it is to call ggc_alloc.
>    *_alloc will be called far more often than the walking function.
>    pool_alloc will provide contiguous memory which will make
>    traversing the basic blocks--a common operation in gcc--cheaper.

> 2) When you do walk, the walking function is going to be cheaper at
>    runtime if the structures being walked are allocated contiguously.

Which once again brings to the point that the issue is not so much
whether memory is in the GC memory pool or not, but rather to how it's
allocated.

If we could allocate object pools in GC memory such that they are
contiguous and a single allocation is involved, then ggc_alloc might
still be more expensive than pool_alloc, and so much so that the need
to register and deregister the object as a root wouldn't make up for
it.  It just so happens that the GGC design doesn't make it exactly
trivial to manage pools of objects.

The other take-out point is that ggc_alloc seems to suck rocks, so
perhaps improving it should have much higher priority than moving
stuff out of GC memory, since this would then benefit everything else
*while* accomplishing the goal of speeding up manual memory
management, such that the issue of whether or not the object is in GC
memory (a mere consequence of the allocation function was selected to
allocate it) becomes less relevant.

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

> The GC code needs to know the complete type of every object you put
> into GC,

For PCH, yes.  For GC only, all we need is the ability to walk such
objects and mark those referenced from it.  This might require some
additional meta-information, but it's far from unworkable.

Of course just using an obstack or some such is trivial in comparison,
but when you take into account that pointing to GC objects requires
you to explicitly register and deregister every pointer to GC objects
stored in the obstack, you realize that this is the same additional
meta-information mentioned in the previous paragraph.

How to express it is "just a matter of programming" ;-)

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


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