This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Speed up garbage collector
- To: Ira Ruben <ira at apple dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Subject: Re: Speed up garbage collector
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Tue, 26 Jun 2001 21:19:28 -0700
--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