Re: gcc 3.3 garbage collector defaults

[Matt Austern <austern at apple dot com>]

On Wednesday, January 29, 2003, at 03:44 AM, Richard Earnshaw wrote:

> > > That's not quite a test of how much memory gets allocated,
> > > but, if we've turned off the collector, it shouldn't be so very
> > > different.  If allocation patterns have changed, looks like the
> > > change is something more subtle.
> > Could it be a cache thrashing due to different usage patterns? Should 
> > be
> > easy to check for using a tool like oprofile on linux, which can
> > report the hardware cachemiss counters.
> >
> > Or you could run it in cachegrind.
> We've been through this discussion before, but let me try and add some
> diagrams that show why I think the GC model is leading to poor 
> performance.
      <technical arguments snipped>

I find these arguments plausible (hard data backed up by measurements
would be nice, of course).  However, I don't think they're directly 
relevant
to the problem we're looking at right now.  Two semi- or non-technical
points:

First, I don't see us getting rid of the garbage collector for the 3.3 
release.
I can just barely imagine getting rid of the garbage collector in some
future release if we decide that it's very important to do so, but a 
major
destabilizing change like that for something where a release branch
has already been cut?  No way.

Second, we already had a garbage collector in 3.2.  The regression we're
seeing isn't because a garbage collector was introduced---that happened
a long time ago---but because something in the garbage collector, or in 
the
way it's used, got changed recently.  Finding what changed between 3.2
and 3.3 is our immediate need.

			--Matt