[patch] Move loop structures to gc memory

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Mon, May 14, 2007 at 04:24:45PM -0700, Ian Lance Taylor wrote:
>> Daniel Jacobowitz <drow@false.org> writes:
>>
>>> On Mon, May 14, 2007 at 03:37:40PM -0700, Ian Lance Taylor wrote:
>>>> Why do we need the strategy of "GC with explicit death marking?"  What
>>>> goal does that serve?
>>> Exactly this problem.  Which comes up several times a year.
>> How would you characterize the problem being solved?  (It's a serious
>> question.)
> 
> I would characterize it as data with a precisely identifiable
> lifetime, where there is some other advantage to storing it in GC
> memory.

Right.

As a concrete example, I used gcc_free to get a significant (1%?)
speedup in the C++ front end by freeing duplicated FUNCTION_DECLs in
duplicate_decls.  I knew at this point that that the nodes were garbage,
but by ggc_free'ing them, I got much better reuse of memory.  (The next
FUNCTION_DECL allocated ended up in the same memory location.)  Since
FUNCTION_DECLs clearly need to be in GC'd space (until we eliminate GC
altogether, which I'm all for, in principle!), this is, AFAICT, the only
way to get this performance advantage.

I fully agree that avoiding GC space is a good thing.  Furthermore, I
agree that putting things into GC space just because they point to GC
things (even though they themselves have obvious lifetimes) is a
lameness of our GC.  But, I don't think that the use of ggc_free itself
is inherently a mistake.

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