gcc 3.3 garbage collector defaults

[Matt Austern]

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