This is the mail archive of the 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 Tue, 2003-11-18 at 18:40, wrote:
> In message <1069194489.30703.332.camel@p4>, Andrew MacLeod writes:
>  >Thats overall. If we collected between passes, or free'd SSAisms, or
>  >something along those lines, it wouldn't be as bad from function to
>  >function. Sure we'd have a highwater mark, but it wouldnt push the
>  >envelope as much.  Is there a reason we dont collect bewteen functions? 
>  >we know both SSA and RTL aren't going to carry over fom one function to
>  >the next.  (Don't we?? :-)
> Err, what do you mean we don't collect between functions?  I'm pretty sure
> we do collect between functions.  Hell, at the RTL level, we collect between
> optimization passes :-)
> Now, we may have some problems with templates and such since I think
> they are considered "nested" functions.  I've got a message from Steven
> regarding that issue that I'll need to look at carefully.

I ASSUME since I only see the [..->..} message rarely that it occurs
whenever we GC.  Certainly wouldn't be the first time I make an ASS out
of not U and just ME :-)

>  >Sigh. I dont suppose there would be a simple way to combine GC and a
>  >machanism for using GC memory, yet knowing when we are done with memory.
>  >When we get rid of a PHI node, we know we're done with it. It would be
>  >awful nice if we could say we're done with this, so it get put on a free
>  >list, and used the next time we need a PHI node. It seems silly to
>  >ignore this kind of information simply because we have  agarbage
>  >colector that will figure it out for us.So have GC, and GC_free()..
> Well the fundamental problem is the garbage collector collects pages,
> not the underlying objects on those pages.
> So to do what you want, you need to ensure that the PHI nodes (or SSA_NAMEs)
> are all allocated on the same page, then you release the page.  The thing
> to watch out for is that we don't end up effectively recreating obstacks
> which had zone-like qualities, but sucked in more ways than I care to
> remember.
> I believe this is the kind of issue the zone allocator is supposed to
> help with.  I haven't looked at it though.
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.

Oops, did I just speak well of that unspoken satanic bastard child? we
need to be careful we dont recreate them here. <shudder> Im sure there
are enough still unhealed festering wounds to prevent that :-)  and
probably so within my lifetime! :-) I think I still have a few myself.

Daniel, you don't have an GC_ObstackII:The_Return.[ch] do you?

:-) There. Now I've amused at least myself for the remainder of the
evening -) 


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