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:

> What I was trying to compare is the overheads of maintaining it as
> either a GC root out of GC memory, that requires some explicit or
> internal-to-GC data structure to keep it as part of the set of dynamic
> GC roots, and some internal-to-memory-mgmt data structure to keep it
> as part of the non-GC memory pool, or a regular GC-able object, which
> requires something to keep it from being collected (perhaps some
> gc_dynamic_roots linked list) and some internal-to-GC data structure
> to keep it as part of the GC memory pool.
> 
> Both require similar walking functions, so this doesn't make much of a
> difference.  I don't see that the overheads in terms of memory are
> significantly different for the two cases.  If you get to run a pass
> of garbage collection, you're going to walk all live objects,
> including all roots, just the same, so I don't see that this pushes
> the balance one way or another either.

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.


> 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, so I think this can only work for obstacks that only hold one
type of object.  And obstacks routinely have unused data in the middle
of the obstack, because it is cheaper to leave it there than to dig it
out; how will the GC walk know the data is free?


I don't really know where you're going with this.

The dynamic registration of walking functions you proposed does seem
like a positive step to me.  It seems that we could use that
functionality to move basic blocks out of GC memory and keep the loop
structures out of GC memory.

Ian


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