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: [tree-ssa PATCH] Pick memory consumption low hanging fruit


On Wed, 2003-11-19 at 10:44, law@redhat.com wrote:

>  >I ASSUME since I only see the [..->..} message rarely that it occurs
>  >whenever we GC.
> Yes.  But also remember that we only GC when the heuristics think it's
> worth the trouble.  If you've got a lot of memory in your machine and you
> do not have checking enabled, then we'll go a lot longer before the GC
> system does anything.

even if you directly call ggc_collect() after we finish with every
function? So calls to ggc_collect() are considered a hint? :-)

> 
>  >It seems like a different beast to me. I hate to say it but there were
>  >certain characterisitics about obstacks that were good in general
>  >intent... probably what spawned them in the first place. It was more the
>  >implmementation and actual usage that were bad.  Dont get me wrong, they
>  >drove me nuts. For slightly, but important, different reasons than we're
>  >talking about here.
> Most definitely they had certain characteristics that were helpful and
> others which were insanely bad.   The hell of it is we had a "one or
> the other" kind of system -- we don't have a scheme which allows us to
> mix-n-match based on the characteristics of the objects we are allocating.
> 
It would be nice if you could call ggc_free() on anything that that was
allocated and have just it collected immediately and available for
reallocation. Anything which doesnt get ggc_freed would be collected the
normal way.

Of course, that might be asking too much :-) And of course that'd open
up the "I freed this thing but someone is still using it" problem...
sigh. blah.

However, I do really like the idea of allocating all the SSA_NAMEs and
PHI_NODEs in their own pages/zones. so we'd need a ggc_alloc_ssatree()
call for those I guess.  VDEF, EEXIT, EKILL, EUSE and EPHIs would fall
into that category/zone as well. 

Is the zone allocator functional and good to go, or are there issues?

Andrew 


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