Re: Locality problems caused by size based allocation?

[Daniel Berlin <dberlin@dberlin.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