Re: [tree-ssa PATCH] Pick memory consumption low hanging fruit

[law at redhat dot com]

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.

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


jeff