Re: Locality problems caused by size based allocation?

[Daniel Berlin <dberlin at dberlin dot org>]

On Tuesday, December 17, 2002, at 08:12  PM, Zack Weinberg wrote:

> Daniel Berlin <dberlin@dberlin.org> writes:
>
> > On Tue, 17 Dec 2002, Jeff Sturm wrote:
> > > What exactly is "size based allocation"?
> > What ggc-page does, which is segregate objects based on size rather 
> > than
> > age or object type.
> >
> > This doesn't work well for RTL, for instance, where you have 3 (or 
> > was it
> > 2 or 4, i forget which) sizes of RTL, so size allocation guarantees 
> > that
> > in a linear walk of RTL, you'll end up moving across all different
> > random pages.
> FYI, I plan to address this particular issue after the New Year, by
> picking up Dave Miller's suggestion from awhile back to avoid ever
> allocating long-lived RTL, and then reverting RTL to obstacks -- but
> just one obstack, data on which lives only during calls to expand_body
> (or something like that).
obstacks aren't something we should revert to.
Implement a pool/subpool system like APR has, or copy the region stuff 
out of libbanshee/libcompat  (it does subregions and whatnot. It's 
actually part of a runtime system for a compiler based partly on gcc 
that does safe regions, so it's rather well implemented).  It will 
compile without problems and without anything outside that directory 
being needed (it has a name conflict in profile.[ch], but renaming 
works fine)
Obstacks just don't have enough flexibility or promise that we should 
go back to them.
It doesn't change the greater locality problem however.
I would think mark and sweep regions/pools (you can have subpools and 
whatnot, for per iteration things) per pass, one for rtl, and one for 
trees, would be a better idea.
> zw