This is the mail archive of the
mailing list for the GCC project.
Re: zack's todo list
On Mon, Nov 13, 2000 at 10:21:59AM -0800, Mark Mitchell wrote:
> * GC performance
> - Get strings out of the GC arena. (patch submitted)
> - Get Laurnyas and Alexandre's patch to make ggc-page usable without
> mmap applied, so we can throw away ggc-simple.
> - Split arena into separate tree, RTL, misc pools.
> - Dual mark bits for trees; avoids millions of calls to ggc_set_mark.
> (Requires separate pools.)
> - Look into not rounding all allocations up to powers of two.
> (Saves large amount of memory.)
> - Better GC statistics.
> These are all good things. We want to go to a generational collector,
> methinks, and I think I know how -- it's actually not a major change
> once trees and rtl are in their own pools.
Okay, so would you mind reviewing the revised string-pool patch? Most
of the other stuff is blocked on that one.
Despite what I said last week, the xvalloc patch could go in as is -
it's just that it could be better still. (There remains a risk of
wasting a page for every page allocated on really perverse systems.)
I don't know how to do generational collection, but if you do, great.
I'm mostly looking at throttling calls to ggc_set_mark, and reducing
memory consumption (ergo cache thrashing).
> * Junk allocations
> - Make __FUNCTION__ et al allocate the string only when used.
> (Avoids pointless allocation of strings and decl structures for
> every function. May mean we don't need prune_unused_decls
> - Lazy make_decl_rtl - avoid allocating symbol_ref RTLs when they
> won't ever be used.
> - Don't create a complete IDENTIFIER_NODE for DECL_ASSEMBLER_NAME.
> Likewise, these are good -- but may not be required for 3.0. I don't
> see these as necessary; the GC work may be in order to get back lost
> compile-time performance.
They're on my list because #3 performance problem in my tests (after
ggc_set_mark and cse_main) is cache thrashing. Reducing memory wasted
should directly translate to performance improvements.