This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Steven Bosscher <s dot bosscher at student dot tudelft dot nl>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: 19 Nov 2003 11:08:23 -0500
- Subject: Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit
- References: <200311191544.hAJFiPD7009032@speedy.slc.redhat.com>
On Wed, 2003-11-19 at 10:44, email@example.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
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...
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?