This is the mail archive of the 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]
Other format: [Raw text]

Re: Faster compilation speed

> It could've been interesting to try incremental/generational collection.
> I didn't do that.

There may be quite a few ways to improve locality if that is the problem
(maybe the problem could just be that GC causes a bigger footprint and thereby
affects the hit rates).


Subpools (give allocations a name and put like named allocations together),
for example "Front End" and "Back End".

Hints about allocations that are likely to be long and short lived. Put them
in different places.

"Allocate Near" models where you give a pointer that gives a hint where you
want the next thing allocated.

Some big functions should only be optimised in chunks perhaps. This could
avoid walking long lists that are bigger than cache, and reduce the damage of
various non-linear algorithms:

big.c:999999: Warning: "This function is too big to optimise in a reasonable

Compaction of allocations after freeing memory, perhaps combined with other
options. This requires knowing about all the users of that memory so pointers
can be updated. Indirect pointers perhaps?

Allocate all sizes together. This would make reuse of storage harder of course
but could improve locality.

Explicitly freeing stuff when you know you are the only user.

Allocating certain things in 'never to be freed' mode, thus avoiding having to
GC it all the time. These could be all put together with no need for bitmaps,
holes in allocated memory etc etc.

Maybe some things should be allowed to migrate out of cache and never return.
Maybe freeing them is worse than leaving them alone.


One problem is that GCC is so complex and large it is difficult to try

It is pretty easy to effectively turn off GC, just increase the size below
which GC does nothing - hardcoded in ggc-page.c (GGC_MIN_LAST_ALLOCATED)
default is 4mb.

Tim Josling

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