gcc 3.3 garbage collector defaults

[Ziemowit Laski]

On Monday, Jan 27, 2003, at 14:52 US/Pacific, Matt Austern wrote:

> On Monday, January 27, 2003, at 02:03 PM, Neil Booth wrote:
>
>> Zack Weinberg wrote:-
>>
>>>> Why aren't the defaults sane???
>>>
>>> I imagine they were sane for when they were introduced, and have 
>>> never
>>> been reexamined since?
>>
>> Let's not get carried away, though, and compare post-GC-fudge
>> performance to pre-GC-fudge performance and claim we're doing better.
>
> That's an important point.  Do we believe that this regression is 
> because
> the gc defaults have changed?  (Not a rhetorical question: I haven't 
> seen
> evidence one way or the other.)  If yes, then this is a fix.  If not, 
> then it's a
> useful change but there's still a regression that we need to identify.

FWIW, I believe the defaults have _not_ changed.  The 3.2.1 ggc has
(in ggc-page.c)

   #define GGC_MIN_EXPAND_FOR_GC (1.3)
   #define GGC_MIN_LAST_ALLOCATED (4 * 1024 * 1024)

whereas the 3.3 branch has (in params.def)

   # define GGC_MIN_EXPAND_DEFAULT 30
   # define GGC_MIN_HEAPSIZE_DEFAULT 4096

These _seem_ to be used in a semantically equivalent fashion
by the ggc_collect() routines in the two compilers.  However,
the ggc machinery did undergo a substantial rewrite
between 3.2.1 and 3.3.  I do not have the expertise to evaluate
a performance impact, if any.  Also, I do not know whether
3.3's ggc has to deal with more objects than 3.2.1; it seems
reasonable that it could.

My 2 zlotys for now,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477