This is the mail archive of the gcc@gcc.gnu.org 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]

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

zw

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