Re: fix c++ gc problems following t_r_o_c

["Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>]

 > From: Geoff Keating <geoffk@geoffk.org>
 > 
 > > X-Original-To: geoffk@foam.wonderslug.com
 > > Date: Thu, 4 Sep 2003 00:29:06 -0400 (EDT)
 > > From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
 > > Cc: gcc-patches@gcc.gnu.org, geoffk@geoffk.org
 > > X-OriginalArrivalTime: 04 Sep 2003 08:16:18.0377 (UTC) FILETIME=[D1157B90:01C372BC]
 > > 
 > >  > On Wed, Sep 03, 2003 at 04:27:28PM -0700, Geoff Keating wrote:
 > >  > > Maybe we should have a 'gcsc', GC Sometimes Collect, which can be on
 > >  > > by default in enable-checking builds and doesn't cost quite so much as
 > >  > > gcac.
 > >  > 
 > >  > That'd be nice.
 > >  > r~
 > > 
 > > I don't know that we need a separate setting.  If you can live without
 > > it the following patch should do the trick.  The patch causes GCC to
 > > default to the gcc-3.2.x collection values (i.e. 30% min-expand and
 > > 4Mb min-heap) when 'gc' checking is enabled, and this setting is
 > > already "on" by default on mainline.
 > 
 > I'm not not so sure about this patch.  It'll mean that sometimes, we
 > have a bug that can never happen in a regular --enable-checking build,
 > but can happen to end-users using a released GCC together with a
 > specific hardware configuration.

Your scenario is already the case today because the physmem values on
your hardware probably have no relation to that on the end-user
hardware.  If a bug is GC related one must supply the end-user's
values for --param ggc-min-expand=X --param ggc-min-heapsize=Y to
completely reproduce their environment and the bug.  These flags will
continue to override the defaults and will be useful for debugging
regardless of whether my patch goes in.

What my patch does is simply give consistently low default values
because recent experience has shown that we're more likely to
encounter (and hopefully fix) bugs if we collect more often.  If I
understand your approach correctly, the only difference is that you
turn on the low defaults by a separate configure parameter but still
enable it on by default in checking builds.  I don't see this as a
meaningful difference because we'd want exactly identical collection
parameters and the ability to set them at GCC runtime trumps the need
for a GCC configure-time flag.

Given this, do you still have any objections?

		--Kaveh
--
Kaveh R. Ghazi			ghazi@caip.rutgers.edu