Re: [patch] Move loop structures to gc memory

[Mark Mitchell <mark at codesourcery dot com>]

Alexandre Oliva wrote:

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

Rather, between GC-allocated and points-to-GC-allocated.  The point is
that these are logically distinct concepts; our implementation conflates
them.

To see why this is undesirable, consider suppose that you want to
allocate some temporary memory, which an obvious lifetime, which will
point to TREEs.  Some of the TREEs may be pointed to *only* from this
temporary memory.  You want to be able to run the collector while this
temporary memory is allocated.  So, it's important that the GC system
know that there are roots in this temporary memory.

In our current system, you must GC-allocate this temporary memory.  (For
example, you can't use alloca, or obstacks, both of which are very fast
allocation schemes.)  Then, when you're done with the temporary memory,
you must wait for the collector to collect it -- or explicitly ggc_free
it.

If you're in the camp that wants to avoid ggc_free, you have to wait for
this memory to be collected, by which point you'll probably have
allocated more stuff, which could have been more efficiently put in the
in-cache now-garbage memory, but wasn't put there because that memory
hadn't been collected yet.

If you're willing to use ggc_free, you can reclaim the memory in timely
fashion, and thus avoid the locality problem, but you still have to use
our relatively expensive GC-allocation/deallocation functions, rather
than the more efficient alloca/obstack (or, even, probably, malloc)
family of functions.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713