This is the mail archive of the gcc-patches@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: Speed up garbage collector




--On Tuesday, June 26, 2001 02:11:40 PM -0700 Ira Ruben <ira@apple.com> 
wrote:

> The 3.x garbage collector, according to gprof measurements, can be
> changed to have a less of an impact by changing GGC_MIN_EXPAND_FOR_GC and
> GGC_MIN_LAST_ALLOCATED

I think we should be careful going down this path.  Increasing the memory
usage is a very major issue; we already start swapping on some not too
big files on moderately reasonable systems and if we start to swap we
far outweight the benefits of your change.  Instead, what we want is
a generational collector -- I know how to do this, but I haven't had
the resources to do it just yet.

In any case, we don't do the commenting-out-of-old-code bit; when you send
a patch just remove what was there before.  The macroizing of
lookup_page_table_entry shouldn't matter when you bootstrap the compiler
unless the inliner is broken.  Another micro-optimization is that you
get a big win if you make the page size a known constant so that the
compiler can fold the shift and mask operations better.  Of course,
on real systems the page size is variable.  A way around this is to
use a fixed page size (say 4K) and then if the system uses a different
page size, suballocate the system page size into 4K chunks.  I didn't
do this -- but I hardwired the page size on x86 GNU/Linux and I saw
a measurable (several percent) improvement.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com


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